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

[Justin Iurman <justin.iurman@gmail.com>]

On 5/24/26 16:26, Ido Schimmel wrote:
> 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?

Sure, will do. In case I forget, don't hesitate to remind me offline.