netdev - Clarification on TC8 Test Failures in Linux Kernel 6.1

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

Message-ID:
 <BL4PR12MB9477612CCED2AE0CA37D9312B0192@BL4PR12MB9477.namprd12.prod.outlook.com>
Date: Wed, 15 Jan 2025 09:42:19 +0000
From: Narayana Reddy P <narayanr@...dia.com>
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Clarification on TC8 Test Failures in Linux Kernel 6.1

Hi Open Source Team,
As part of the TC8 testing (test cases can be referred from this https://opensig.org/wp-content/uploads/2024/09/OA_Automotive_Ethernet_ECU_TestSpecification_Layer_3-7_v3.0-_final.pdf), we are validating the test cases. However, the following tests are failing, and I would like to know if these failures are related to any known issues or expected changes in Kernel 6.1 due to any of the recent enhancements for corresponding RFCs:

1. IPv4_REASSEMBLY_13: IP Fragments overlap check
	Based on my analysis, duplicate fragments are being dropped in the kernel. I attempted reverting the change mentioned in https://lore.kernel.org/lkml/20181213112748.GF21324, but it did not resolve the issue.
2. TCP_NAGLE_03: Buffer all user data until a full-sized segment
3. IPv4_AUTOCONF_CONFLICT_10: Receiving a conflicting ARP packet
	Test case IPv4_AUTOCONF_CONFLICT_09 passes, as the device modifies the target address when two conflicts are observed.
	However, with a single conflict packet, the device does not respond, leading to the failure.
4. IPv4_AUTOCONF_CONFLICT_11: ARP packets containing (Link-Local 'sender IP address') rule - I
	As per the test case, the ARP response should use a broadcast (BC) address, but the device is responding with a unicast (UC) address, causing the failure.

Additional Information:
All the above tests are failing on both Kernel 5.15 and Kernel 6.1.

Observation:
TCP_UNACCEPTABLE_04: [established] out-of-window SEQ/unacceptable ACK -> empty message with SEQ [established]
This test case also failed on Kernel 6.1. However, after reverting the change introduced in https://patchwork.kernel.org/project/netdevbpf/patch/20231205161841.2702925-1-edumazet@google.com/#25623591, the test passed successfully.

Could you please confirm if the failures for the four tests mentioned above are expected deviations for Linux Kernel 6.1?
Looking forward to your insights.

Best regards,
Narayan Reddy