linux-kernel - Re: [PATCH v6 0/2] lib: checksum: Fix issues with checksum tests

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 for Android: free password hash cracker in your pocket

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

Message-ID: <8dedf370-47e1-405d-85cf-53f3acfa16a0@roeck-us.net>
Date: Sun, 11 Feb 2024 11:18:36 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Charlie Jenkins <charlie@...osinc.com>,
 David Laight <David.Laight@...lab.com>, Palmer Dabbelt <palmer@...belt.com>,
 Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v6 0/2] lib: checksum: Fix issues with checksum tests

Hi,

On 2/7/24 16:22, Charlie Jenkins wrote:
> The ip_fast_csum and csum_ipv6_magic tests did not have the data
> types properly casted, and improperly misaligned data.
> 
> Signed-off-by: Charlie Jenkins <charlie@...osinc.com>

I sorted out most of the problems with this version, but I still get:

     # test_csum_ipv6_magic: ASSERTION FAILED at lib/checksum_kunit.c:513
     Expected ( u64)csum_result == ( u64)expected, but
         ( u64)csum_result == 16630 (0x40f6)
         ( u64)expected == 65535 (0xffff)
     not ok 5 test_csum_ipv6_magic

on m68k:q800. This is suspicious because there is no 0xffff in
expected_csum_ipv6_magic[]. With some debugging information:

####### num_tests=86 i=84 expect array size=84
####### MAX_LEN=512 WORD_ALIGNMENT=4 magic data size=42

That means the loop

	for (int i = 0; i < num_tests; i++) {
		...
		expected = (__force __sum16)expected_csum_ipv6_magic[i];
		...
	}

will access data beyond the end of the expected_csum_ipv6_magic[] array,
possibly because m68k doesn't pad struct csum_ipv6_magic_data to 44 bytes.

In this context, is the comment about proto having to be 0 really true ?
It seems to me that the calculated checksum must be identical on both
little and big endian systems. After all, they need to be able to talk
to each other.

Thanks,
Guenter