Re: [PATCH net 1/1] ipv6: exthdrs: refresh nh after handling HAO option

[Ido Schimmel <idosch@nvidia.com>]

On Fri, May 22, 2026 at 01:30:40PM +0200, Justin Iurman wrote:
> On 5/22/26 11:42, Ren Wei wrote:
> > From: Zhengchuan Liang <zcliangcn@gmail.com>
> > 
> > ip6_parse_tlv() caches skb_network_header(skb) in nh while walking
> > IPv6 TLVs.
> > 
> > ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can
> > move the skb head and invalidate the cached network header pointer.
> > Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs
> > are parsed from the current skb head.
> > 
> > This matches the existing pattern used in ip6_parse_tlv() after helpers
> > that can modify skb header storage.
> > 
> > Fixes: a831f5bbc89a ("[IPV6] MIP6: Add inbound interface of home address option.")
> > Cc: stable@kernel.org
> > Reported-by: Yuan Tan <yuantan098@gmail.com>
> > Reported-by: Xin Liu <bird@lzu.edu.cn>
> > Co-developed-by: Luxing Yin <tr0jan@lzu.edu.cn>
> > Signed-off-by: Luxing Yin <tr0jan@lzu.edu.cn>
> > Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com>
> > Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> > Assisted-by: Codex:gpt-5.4

Reviewed-by: Ido Schimmel <idosch@nvidia.com>

> > ---
> >   net/ipv6/exthdrs.c | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
> > index 47c5502a34a2..751e07392aae 100644
> > --- a/net/ipv6/exthdrs.c
> > +++ b/net/ipv6/exthdrs.c
> > @@ -201,6 +201,8 @@ static bool ip6_parse_tlv(bool hopbyhop,
> >   				case IPV6_TLV_HAO:
> >   					if (!ipv6_dest_hao(skb, off))
> >   						return false;
> > +
> > +					nh = skb_network_header(skb);
> >   					break;
> >   #endif
> >   				default:
> 
> Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
> 
> Note that the same issue applies to IPV6_TLV_JUMBO (hopopts), I've sent a
> patch to fix it as well (see [1]). Which makes me wonder... at some point,
> we may refresh the nh pointer once by default, regardless of the option. The
> impact wouldn't be that huge, and it would avoid missing the above for
> similar (new) cases.

+1

Do you want to send such a patch to net-next once both patches are
present there?