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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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