linux-kernel - Re: [PATCH] parisc: Fix csum_ipv6

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: Sun, 11 Feb 2024 06:09:14 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: David Laight <David.Laight@...LAB.COM>, Helge Deller <deller@....de>
Cc: "James E . J . Bottomley" <James.Bottomley@...senPartnership.com>,
 "linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 Charlie Jenkins <charlie@...osinc.com>, Palmer Dabbelt <palmer@...osinc.com>
Subject: Re: [PATCH] parisc: Fix csum_ipv6_magic on 32-bit systems

On 2/11/24 05:57, David Laight wrote:
> From: Guenter Roeck
>> Sent: 10 February 2024 19:16
>>
>> Calculating the IPv6 checksum on 32-bit systems missed overflows when
>> adding the proto+len fields into the checksum. This results in the
>> following unit test failure.
>>
>>      # test_csum_ipv6_magic: ASSERTION FAILED at lib/checksum_kunit.c:506
>>      Expected ( u64)csum_result == ( u64)expected, but
>>          ( u64)csum_result == 46722 (0xb682)
>>          ( u64)expected == 46721 (0xb681)
>>      not ok 5 test_csum_ipv6_magic
>>
>> This is probably rarely seen in the real world because proto+len are
>> usually small values which will rarely result in overflows when calculating
>> the checksum. However, the unit test code uses large values for the length
>> field, causing the test to fail.
> 
> Isn't length limited by the protocol encoding?
> So this is really a bug in the unit tests for using a length that
> it too large for the function?
> 

Arguable. While the length value passed to the function is not a valid
packet length, it exposes a weakness in the implementation of
csum_ipv6_magic() - after all, folding proto+len into the checksum _may_
overflow even for small(er) values of proto and length. It is just much
less likely to happen if the length is limited to 16 bit.

Guenter