netdev - Re: With regard to processing overlapping fragment packet

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 26 May 2020 09:54:17 +0200
From:   Michal Kubecek <mkubecek@...e.cz>
To:     netdev@...r.kernel.org
Cc:     강유건 <yugun819@...pkinnet.com>
Subject: Re: With regard to processing overlapping fragment packet

On Tue, May 26, 2020 at 02:47:25PM +0900, 강유건 wrote:
> Hello
> 
> Actually, I'm not sure if it's right to send mail here.
> 
> I'm testing ipv6ready Self Test 5.0.4 using linux-4.19.118 kernel.
> ( https://www.ipv6ready.org.cn/home/views/default/resource/logo/phase2-core/index.htm
> )
> 
> Test failed in 82. Part B: Reverse Order Fragments ( Link-Local ) in
> Section 1. spec
> 
> In test 82, source transmits 3 fragment packets in reverse order that
> are originally a icmpv6 packet.
> There is an overlapping interval between the 2nd and 3rd packet.
> 
> The test requires the destination MUST drop all packets and respond nothing,
> but the dest replies Time Exceeded / Reassembly Timeout.
> 
> I've read some /net/ipv6 codes and think when the kernel receives the
> 2nd packet ( overlapping occurs ), it drops 3rd and 2nd packets and
> recognizes the 1st packet as a new fragment packet.
> ( Is it right ? )
> 
> In RFC5722, when a node receives the overlapping fragment, it MUST
> discard those not yet received. (  In this case, I think it applies to
> 1st packet )
> 
> Please let me know if I misunderstood RFC or if it wasn't implemented
> in the kernel.

You understood the requirement of the RFC correctly but the problem is
that implementing it would be too complicated, would make the
implementation susceptible to DoS attacks and could even result in
dropping legitimate (new) fragments. Therefore an erratum to RFC 5722
was accepted which drops the requirement to also drop fragments not
received yet:

  https://www.rfc-editor.org/errata/eid3089

Michal