Re: [PATCH v2] net: ipv6: fix wrong start position when receive hop-by-hop fragment

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 22 Apr 2024 17:19:17 +0800 gaoxingwang wrote:
> In IPv6, ipv6_rcv_core will parse the hop-by-hop type extension header and increase skb->transport_header by one extension header length.
> But if there are more other extension headers like fragment header at this time, the skb->transport_header points to the second extension header,
> not the transport layer header or the first extension header.
> 
> This will result in the start and nexthdrp variable not pointing to the same position in ipv6frag_thdr_trunced,
> and ipv6_skip_exthdr returning incorrect offset and frag_off.Sometimes,the length of the last sharded packet is smaller than the calculated incorrect offset, resulting in packet loss.
> We can use network header to offset and calculate the correct position to solve this problem.
> 
> Fixes: 9d9e937b1c8b (ipv6/netfilter: Discard first fragment not including all headers)

nits:
 - this is not correct format for Fixes, missing quotes
 - please wrap the message at 72 chars
 - please make sure you add spaces after punctuation
 - please make sure you don't send new version of the patch in reply to
   old, add a lore link to previous version under --- instead

About the code - how are you testing this?
What's the packet you're saying we drop?

If transport_header can't be trusted there may be more in this
function to fix..
-- 
pw-bot: cr