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

Date:   Tue, 26 May 2020 14:47:25 +0900
From:   강유건 <yugun819@...pkinnet.com>
To:     netdev@...r.kernel.org
Subject: With regard to processing overlapping fragment packet

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.

Thank you for reading the long article!

-- Yugeon Kang

-- 

강 유 건 사원

펌킨네트웍스㈜ 개발1팀

08380 서울시 구로구 디지털로31길 20 에이스테크노타워 5차 405호

Direct: 070-4263-9937

Mobile: 010-9887-3517

E-mail: yugun819@...pkinnet.com

Tel: 02-863-9380, Fax: 02-2109-6675

www.pumpkinnet.co.kr

Download attachment "82_html_Link0 (1).pcap" of type "application/octet-stream" (1460 bytes)

Download attachment "rfc5722.PNG" of type "image/png" (15381 bytes)