linux-kernel - Problems with csum_partial with misaligned buffers on sh4 platform

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]

Message-ID: <65ed7c95-712c-410b-84f3-58496b0c9649@roeck-us.net>
Date: Sat, 10 Feb 2024 07:12:39 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Yoshinori Sato <ysato@...rs.sourceforge.jp>
Cc: Rich Felker <dalias@...c.org>,
	John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
	linux-sh@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Problems with csum_partial with misaligned buffers on sh4 platform

Hi,

when running checksum unit tests on sh4 qemu emulations, I get the following
errors.

    KTAP version 1
    # Subtest: checksum
    # module: checksum_kunit
    1..5
    # test_csum_fixed_random_inputs: ASSERTION FAILED at lib/checksum_kunit.c:500
    Expected ( u64)result == ( u64)expec, but
        ( u64)result == 53378 (0xd082)
        ( u64)expec == 33488 (0x82d0)
    not ok 1 test_csum_fixed_random_inputs
    # test_csum_all_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:525
    Expected ( u64)result == ( u64)expec, but
        ( u64)result == 65281 (0xff01)
        ( u64)expec == 65280 (0xff00)
    not ok 2 test_csum_all_carry_inputs
    # test_csum_no_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:573
    Expected ( u64)result == ( u64)expec, but
        ( u64)result == 65535 (0xffff)
        ( u64)expec == 65534 (0xfffe)
    not ok 3 test_csum_no_carry_inputs
    ok 4 test_ip_fast_csum
    ok 5 test_csum_ipv6_magic
# checksum: pass:2 fail:3 skip:0 total:5

The above is with from a little endian system. On a big endian system,
the test result is as follows.

    KTAP version 1
    # Subtest: checksum
    # module: checksum_kunit
    1..5
    # test_csum_fixed_random_inputs: ASSERTION FAILED at lib/checksum_kunit.c:500
    Expected ( u64)result == ( u64)expec, but
        ( u64)result == 33488 (0x82d0)
        ( u64)expec == 53378 (0xd082)
    not ok 1 test_csum_fixed_random_inputs
    # test_csum_all_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:525
    Expected ( u64)result == ( u64)expec, but
        ( u64)result == 65281 (0xff01)
        ( u64)expec == 255 (0xff)
    not ok 2 test_csum_all_carry_inputs
    # test_csum_no_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:565
    Expected ( u64)result == ( u64)expec, but
        ( u64)result == 1020 (0x3fc)
        ( u64)expec == 0 (0x0)
    not ok 3 test_csum_no_carry_inputs
    # test_ip_fast_csum: ASSERTION FAILED at lib/checksum_kunit.c:589
    Expected ( u64)expected == ( u64)csum_result, but
        ( u64)expected == 55939 (0xda83)
        ( u64)csum_result == 33754 (0x83da)
    not ok 4 test_ip_fast_csum
    # test_csum_ipv6_magic: ASSERTION FAILED at lib/checksum_kunit.c:617
    Expected ( u64)expected_csum_ipv6_magic[i] == ( u64)csum_ipv6_magic(saddr, daddr, len, proto, csum), but
        ( u64)expected_csum_ipv6_magic[i] == 6356 (0x18d4)
        ( u64)csum_ipv6_magic(saddr, daddr, len, proto, csum) == 43586 (0xaa42)
    not ok 5 test_csum_ipv6_magic
# checksum: pass:0 fail:5 skip:0 total:5

Note that test_ip_fast_csum and test_csum_ipv6_magic fail on all big endian
systems due to a bug in the test code, unrelated to this problem.

Analysis shows that the errors are seen only if the buffer is misaligned.
Looking into arch/sh/lib/checksum.S, I found commit cadc4e1a2b4d2 ("sh:
Handle calling csum_partial with misaligned data") which seemed to be
related. Reverting that commit fixes the problem.
This suggests that something may be wrong with that commit. Alternatively,
of course, it may be possible that something is wrong with the qemu
emulation, but that seems unlikely.

Thanks,
Guenter