[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240424195135.76d0f232@kernel.org>
Date: Wed, 24 Apr 2024 19:51:35 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: gaoxingwang <gaoxingwang1@...wei.com>
Cc: <davem@...emloft.net>, <dsahern@...nel.org>, <edumazet@...gle.com>,
<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
<pabeni@...hat.com>, <yanan@...wei.com>
Subject: Re: [PATCH v2] net: ipv6: fix wrong start position when receive
hop-by-hop fragment
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
Powered by blists - more mailing lists