* [linus:master] [crypto] 40b9969796: UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c
@ 2025-05-28 5:15 kernel test robot
2025-05-28 6:14 ` Eric Biggers
0 siblings, 1 reply; 6+ messages in thread
From: kernel test robot @ 2025-05-28 5:15 UTC (permalink / raw)
To: Eric Biggers
Cc: oe-lkp, lkp, linux-kernel, Herbert Xu, linux-arm-kernel,
loongarch, linux-s390, linux-crypto, oliver.sang
Hello,
by this commit, the config has below diff:
--- /pkg/linux/x86_64-randconfig-101-20250522/clang-20/d469eaed223fa485eabebd3bcd05ddd3c891f54e/.config 2025-05-23 23:44:56.781716572 +0800
+++ /pkg/linux/x86_64-randconfig-101-20250522/clang-20/40b9969796bfa49ed1b0f7ddc254f48cb2ac6d2c/.config 2025-05-24 02:08:29.858605300 +0800
@@ -4837,7 +4837,8 @@ CONFIG_CRYPTO_ACOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
-CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
+CONFIG_CRYPTO_SELFTESTS=y
+# CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_PCRYPT=m
CONFIG_CRYPTO_CRYPTD=y
it seems tests are enabled then we observe the UBSAN issues
d469eaed223fa485 40b9969796bfa49ed1b0f7ddc25
---------------- ---------------------------
fail:runs %reproduction fail:runs
| | |
:6 100% 6:6 dmesg.UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c
:6 100% 6:6 dmesg.UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305.c
it's hard for bot to apply this commit to previous commits in bisect, so we just
make out below report FYI that we observe UBSAN issues in boot tests.
kernel test robot noticed "UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c" on:
commit: 40b9969796bfa49ed1b0f7ddc254f48cb2ac6d2c ("crypto: testmgr - replace CRYPTO_MANAGER_DISABLE_TESTS with CRYPTO_SELFTESTS")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
[test failed on linux-next/master 176e917e010cb7dcc605f11d2bc33f304292482b]
in testcase: boot
config: x86_64-randconfig-101-20250522
compiler: clang-20
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202505281024.f42beaa7-lkp@intel.com
[ 12.442846][ T1] ------------[ cut here ]------------
[ 12.443261][ T1] UBSAN: unsigned-integer-overflow in lib/crypto/chacha20poly1305-selftest.c:8854:47
[ 12.444084][ T1] 16 - 114 cannot be represented in type 'size_t' (aka 'unsigned long')
[ 12.444682][ T1] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.15.0-rc5-00342-g40b9969796bf #1 VOLUNTARY
[ 12.444688][ T1] Tainted: [T]=RANDSTRUCT
[ 12.444689][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 12.444691][ T1] Call Trace:
[ 12.444693][ T1] <TASK>
[ 12.444696][ T1] __dump_stack (kbuild/obj/consumer/x86_64-randconfig-101-20250522/lib/dump_stack.c:95)
[ 12.444705][ T1] dump_stack_lvl (kbuild/obj/consumer/x86_64-randconfig-101-20250522/lib/dump_stack.c:123 (discriminator 1))
[ 12.444709][ T1] dump_stack (kbuild/obj/consumer/x86_64-randconfig-101-20250522/lib/dump_stack.c:130)
[ 12.444712][ T1] ubsan_epilogue (kbuild/obj/consumer/x86_64-randconfig-101-20250522/lib/ubsan.c:232 (discriminator 2))
[ 12.444717][ T1] handle_overflow (kbuild/obj/consumer/x86_64-randconfig-101-20250522/lib/ubsan.c:?)
[ 12.444729][ T1] __ubsan_handle_sub_overflow (kbuild/obj/consumer/x86_64-randconfig-101-20250522/lib/ubsan.c:277)
[ 12.444732][ T1] chacha20poly1305_encrypt_bignonce (kbuild/obj/consumer/x86_64-randconfig-101-20250522/lib/crypto/chacha20poly1305-selftest.c:?)
[ 12.444759][ T1] ? kasan_save_alloc_info (kbuild/obj/consumer/x86_64-randconfig-101-20250522/mm/kasan/generic.c:563 (discriminator 1))
[ 12.444766][ T1] chacha20poly1305_selftest_encrypt (kbuild/obj/consumer/x86_64-randconfig-101-20250522/lib/crypto/chacha20poly1305-selftest.c:?)
[ 12.444772][ T1] chacha20poly1305_selftest (kbuild/obj/consumer/x86_64-randconfig-101-20250522/lib/crypto/chacha20poly1305-selftest.c:8903 (discriminator 1))
[ 12.444787][ T1] chacha20poly1305_init (kbuild/obj/consumer/x86_64-randconfig-101-20250522/lib/crypto/chacha20poly1305.c:362)
[ 12.444790][ T1] do_one_initcall (kbuild/obj/consumer/x86_64-randconfig-101-20250522/init/main.c:1257)
[ 12.444793][ T1] ? blake2s_random_test (kbuild/obj/consumer/x86_64-randconfig-101-20250522/lib/crypto/chacha20poly1305.c:360)
[ 12.444801][ T1] ? kasan_save_track (kbuild/obj/consumer/x86_64-randconfig-101-20250522/arch/x86/include/asm/current.h:25 (discriminator 3) kbuild/obj/consumer/x86_64-randconfig-101-20250522/mm/kasan/common.c:60 (discriminator 3) kbuild/obj/consumer/x86_64-randconfig-101-20250522/mm/kasan/common.c:69 (discriminator 3))
[ 12.444803][ T1] ? kasan_save_track (kbuild/obj/consumer/x86_64-randconfig-101-20250522/mm/kasan/common.c:48 kbuild/obj/consumer/x86_64-randconfig-101-20250522/mm/kasan/common.c:68)
[ 12.444804][ T1] ? kasan_save_alloc_info (kbuild/obj/consumer/x86_64-randconfig-101-20250522/mm/kasan/generic.c:563 (discriminator 1))
[ 12.444806][ T1] ? __kasan_kmalloc (kbuild/obj/consumer/x86_64-randconfig-101-20250522/mm/kasan/common.c:398)
[ 12.444808][ T1] ? __kmalloc_noprof (kbuild/obj/consumer/x86_64-randconfig-101-20250522/include/linux/kasan.h:260 kbuild/obj/consumer/x86_64-randconfig-101-20250522/mm/slub.c:4327 kbuild/obj/consumer/x86_64-randconfig-101-20250522/mm/slub.c:4339)
[ 12.444814][ T1] ? do_initcalls (kbuild/obj/consumer/x86_64-randconfig-101-20250522/init/main.c:1329)
[ 12.444817][ T1] ? do_basic_setup (kbuild/obj/consumer/x86_64-randconfig-101-20250522/init/main.c:1355)
[ 12.444824][ T1] ? trace_hardirqs_on (kbuild/obj/consumer/x86_64-randconfig-101-20250522/kernel/trace/trace_preemptirq.c:80)
[ 12.444829][ T1] ? irqentry_exit (kbuild/obj/consumer/x86_64-randconfig-101-20250522/kernel/entry/common.c:358)
[ 12.444834][ T1] ? sysvec_apic_timer_interrupt (kbuild/obj/consumer/x86_64-randconfig-101-20250522/arch/x86/kernel/apic/apic.c:1049 (discriminator 256))
[ 12.444840][ T1] ? do_initcall_level (kbuild/obj/consumer/x86_64-randconfig-101-20250522/init/main.c:1303)
[ 12.444847][ T1] ? next_arg (kbuild/obj/consumer/x86_64-randconfig-101-20250522/lib/cmdline.c:273)
[ 12.444853][ T1] ? parameq (kbuild/obj/consumer/x86_64-randconfig-101-20250522/kernel/params.c:90 (discriminator 1) kbuild/obj/consumer/x86_64-randconfig-101-20250522/kernel/params.c:99 (discriminator 1))
[ 12.444858][ T1] ? parse_args (kbuild/obj/consumer/x86_64-randconfig-101-20250522/kernel/params.c:153 kbuild/obj/consumer/x86_64-randconfig-101-20250522/kernel/params.c:186)
[ 12.444869][ T1] do_initcall_level (kbuild/obj/consumer/x86_64-randconfig-101-20250522/init/main.c:1318 (discriminator 6))
[ 12.444874][ T1] do_initcalls (kbuild/obj/consumer/x86_64-randconfig-101-20250522/init/main.c:1332 (discriminator 2))
[ 12.444878][ T1] do_basic_setup (kbuild/obj/consumer/x86_64-randconfig-101-20250522/init/main.c:1355)
[ 12.444882][ T1] kernel_init_freeable (kbuild/obj/consumer/x86_64-randconfig-101-20250522/init/main.c:1571)
[ 12.444885][ T1] ? rest_init (kbuild/obj/consumer/x86_64-randconfig-101-20250522/init/main.c:1449)
[ 12.444887][ T1] kernel_init (kbuild/obj/consumer/x86_64-randconfig-101-20250522/init/main.c:1459)
[ 12.444890][ T1] ? rest_init (kbuild/obj/consumer/x86_64-randconfig-101-20250522/init/main.c:1449)
[ 12.444892][ T1] ret_from_fork (kbuild/obj/consumer/x86_64-randconfig-101-20250522/arch/x86/kernel/process.c:153)
[ 12.444895][ T1] ? rest_init (kbuild/obj/consumer/x86_64-randconfig-101-20250522/init/main.c:1449)
[ 12.444898][ T1] ret_from_fork_asm (kbuild/obj/consumer/x86_64-randconfig-101-20250522/arch/x86/entry/entry_64.S:255)
[ 12.444909][ T1] </TASK>
[ 12.475589][ T1] ---[ end trace ]---
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20250528/202505281024.f42beaa7-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [linus:master] [crypto] 40b9969796: UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c 2025-05-28 5:15 [linus:master] [crypto] 40b9969796: UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c kernel test robot @ 2025-05-28 6:14 ` Eric Biggers 2025-05-28 16:45 ` Kees Cook 0 siblings, 1 reply; 6+ messages in thread From: Eric Biggers @ 2025-05-28 6:14 UTC (permalink / raw) To: Kees Cook, linux-hardening Cc: oe-lkp, lkp, linux-kernel, Herbert Xu, linux-arm-kernel, loongarch, linux-s390, linux-crypto, kernel test robot [+Kees and linux-hardening] On Wed, May 28, 2025 at 01:15:05PM +0800, kernel test robot wrote: > > > Hello, > > by this commit, the config has below diff: > > --- /pkg/linux/x86_64-randconfig-101-20250522/clang-20/d469eaed223fa485eabebd3bcd05ddd3c891f54e/.config 2025-05-23 23:44:56.781716572 +0800 > +++ /pkg/linux/x86_64-randconfig-101-20250522/clang-20/40b9969796bfa49ed1b0f7ddc254f48cb2ac6d2c/.config 2025-05-24 02:08:29.858605300 +0800 > @@ -4837,7 +4837,8 @@ CONFIG_CRYPTO_ACOMP2=y > CONFIG_CRYPTO_MANAGER=y > CONFIG_CRYPTO_MANAGER2=y > # CONFIG_CRYPTO_USER is not set > -CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y > +CONFIG_CRYPTO_SELFTESTS=y > +# CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is not set > # CONFIG_CRYPTO_NULL is not set > CONFIG_CRYPTO_PCRYPT=m > CONFIG_CRYPTO_CRYPTD=y > > it seems tests are enabled then we observe the UBSAN issues > > d469eaed223fa485 40b9969796bfa49ed1b0f7ddc25 > ---------------- --------------------------- > fail:runs %reproduction fail:runs > | | | > :6 100% 6:6 dmesg.UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c > :6 100% 6:6 dmesg.UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305.c > > it's hard for bot to apply this commit to previous commits in bisect, so we just > make out below report FYI that we observe UBSAN issues in boot tests. > > > kernel test robot noticed "UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c" on: > > commit: 40b9969796bfa49ed1b0f7ddc254f48cb2ac6d2c ("crypto: testmgr - replace CRYPTO_MANAGER_DISABLE_TESTS with CRYPTO_SELFTESTS") > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master > > [test failed on linux-next/master 176e917e010cb7dcc605f11d2bc33f304292482b] > > in testcase: boot > > config: x86_64-randconfig-101-20250522 > compiler: clang-20 > test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G > > (please refer to attached dmesg/kmsg for entire log/backtrace) > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot <oliver.sang@intel.com> > | Closes: https://lore.kernel.org/oe-lkp/202505281024.f42beaa7-lkp@intel.com > > > [ 12.442846][ T1] ------------[ cut here ]------------ > [ 12.443261][ T1] UBSAN: unsigned-integer-overflow in lib/crypto/chacha20poly1305-selftest.c:8854:47 > [ 12.444084][ T1] 16 - 114 cannot be represented in type 'size_t' (aka 'unsigned long') > [ 12.444682][ T1] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.15.0-rc5-00342-g40b9969796bf #1 VOLUNTARY This issue predates the blamed commit, and it's specific to CONFIG_UBSAN_INTEGER_WRAP which was recently introduced. CONFIG_UBSAN_INTEGER_WRAP apparently requires clang 20. To try to reproduce this, I built clang from the release/20.x branch, then built a kernel with CONFIG_UBSAN_INTEGER_WRAP=y. When booting that kernel, there are many UBSAN reports: [ 0.000000] UBSAN: negation-overflow in lib/sort.c:199:36 [ 0.000000] UBSAN: negation-overflow in lib/sort.c:185:14 [ 0.276708] UBSAN: unsigned-integer-overflow in ./include/linux/min_heap.h:329:24 [ 0.277376] UBSAN: negation-overflow in ./include/linux/min_heap.h:260:42 [ 0.871191] UBSAN: unsigned-integer-overflow in lib/crypto/chacha20poly1305-selftest.c:8854:47 [ 0.890856] UBSAN: unsigned-integer-overflow in lib/crypto/chacha20poly1305-selftest.c:8851:47 [ 0.910455] UBSAN: unsigned-integer-overflow in lib/crypto/chacha20poly1305.c:260:57 [ 1.105542] UBSAN: unsigned-integer-overflow in lib/zstd/compress/zstd_compress_sequences.c:334:21 [ 1.113539] UBSAN: unsigned-integer-overflow in lib/zstd/compress/huf_compress.c:889:23 [ 1.114597] UBSAN: unsigned-integer-overflow in lib/lz4/lz4_compress.c:294:9 So I did get the chacha20poly1305 ones, but they're hardly unique. If this new sanitizer is going to move forward, is there any sort of plan or guide for how to update code to be compatible with it? Specifically considering common situations where unsigned wraparound (which is defined behavior in C) can be intentionally relied on, like calculating the distance from the next N-byte boundary. What are the best practices now? Documentation/dev-tools/ubsan.rst says nothing about this and only mentions "undefined behavior", which this is not. - Eric ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linus:master] [crypto] 40b9969796: UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c 2025-05-28 6:14 ` Eric Biggers @ 2025-05-28 16:45 ` Kees Cook 2025-05-28 16:58 ` Arnd Bergmann 2025-05-28 17:15 ` Jann Horn 0 siblings, 2 replies; 6+ messages in thread From: Kees Cook @ 2025-05-28 16:45 UTC (permalink / raw) To: Eric Biggers, Justin Stitt Cc: linux-hardening, oe-lkp, lkp, linux-kernel, Herbert Xu, linux-arm-kernel, loongarch, linux-s390, linux-crypto, kernel test robot, Arnd Bergmann, llvm On Tue, May 27, 2025 at 11:14:27PM -0700, Eric Biggers wrote: > [+Kees and linux-hardening] > > On Wed, May 28, 2025 at 01:15:05PM +0800, kernel test robot wrote: > > > > > > Hello, > > > > by this commit, the config has below diff: > > > > --- /pkg/linux/x86_64-randconfig-101-20250522/clang-20/d469eaed223fa485eabebd3bcd05ddd3c891f54e/.config 2025-05-23 23:44:56.781716572 +0800 > > +++ /pkg/linux/x86_64-randconfig-101-20250522/clang-20/40b9969796bfa49ed1b0f7ddc254f48cb2ac6d2c/.config 2025-05-24 02:08:29.858605300 +0800 > > @@ -4837,7 +4837,8 @@ CONFIG_CRYPTO_ACOMP2=y > > CONFIG_CRYPTO_MANAGER=y > > CONFIG_CRYPTO_MANAGER2=y > > # CONFIG_CRYPTO_USER is not set > > -CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y > > +CONFIG_CRYPTO_SELFTESTS=y > > +# CONFIG_CRYPTO_MANAGER_EXTRA_TESTS is not set > > # CONFIG_CRYPTO_NULL is not set > > CONFIG_CRYPTO_PCRYPT=m > > CONFIG_CRYPTO_CRYPTD=y > > > > it seems tests are enabled then we observe the UBSAN issues > > > > d469eaed223fa485 40b9969796bfa49ed1b0f7ddc25 > > ---------------- --------------------------- > > fail:runs %reproduction fail:runs > > | | | > > :6 100% 6:6 dmesg.UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c > > :6 100% 6:6 dmesg.UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305.c > > > > it's hard for bot to apply this commit to previous commits in bisect, so we just > > make out below report FYI that we observe UBSAN issues in boot tests. > > > > > > kernel test robot noticed "UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c" on: > > > > commit: 40b9969796bfa49ed1b0f7ddc254f48cb2ac6d2c ("crypto: testmgr - replace CRYPTO_MANAGER_DISABLE_TESTS with CRYPTO_SELFTESTS") > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master > > > > [test failed on linux-next/master 176e917e010cb7dcc605f11d2bc33f304292482b] > > > > in testcase: boot > > > > config: x86_64-randconfig-101-20250522 > > compiler: clang-20 > > test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G > > > > (please refer to attached dmesg/kmsg for entire log/backtrace) > > > > > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of > > the same patch/commit), kindly add following tags > > | Reported-by: kernel test robot <oliver.sang@intel.com> > > | Closes: https://lore.kernel.org/oe-lkp/202505281024.f42beaa7-lkp@intel.com > > > > > > [ 12.442846][ T1] ------------[ cut here ]------------ > > [ 12.443261][ T1] UBSAN: unsigned-integer-overflow in lib/crypto/chacha20poly1305-selftest.c:8854:47 > > [ 12.444084][ T1] 16 - 114 cannot be represented in type 'size_t' (aka 'unsigned long') > > [ 12.444682][ T1] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.15.0-rc5-00342-g40b9969796bf #1 VOLUNTARY > > This issue predates the blamed commit, and it's specific to > CONFIG_UBSAN_INTEGER_WRAP which was recently introduced. > > CONFIG_UBSAN_INTEGER_WRAP apparently requires clang 20. > > To try to reproduce this, I built clang from the release/20.x branch, then built > a kernel with CONFIG_UBSAN_INTEGER_WRAP=y. When booting that kernel, there are > many UBSAN reports: > > [ 0.000000] UBSAN: negation-overflow in lib/sort.c:199:36 > > [ 0.000000] UBSAN: negation-overflow in lib/sort.c:185:14 > > [ 0.276708] UBSAN: unsigned-integer-overflow in ./include/linux/min_heap.h:329:24 > > [ 0.277376] UBSAN: negation-overflow in ./include/linux/min_heap.h:260:42 > > [ 0.871191] UBSAN: unsigned-integer-overflow in lib/crypto/chacha20poly1305-selftest.c:8854:47 > > [ 0.890856] UBSAN: unsigned-integer-overflow in lib/crypto/chacha20poly1305-selftest.c:8851:47 > > [ 0.910455] UBSAN: unsigned-integer-overflow in lib/crypto/chacha20poly1305.c:260:57 > > [ 1.105542] UBSAN: unsigned-integer-overflow in lib/zstd/compress/zstd_compress_sequences.c:334:21 > > [ 1.113539] UBSAN: unsigned-integer-overflow in lib/zstd/compress/huf_compress.c:889:23 > > [ 1.114597] UBSAN: unsigned-integer-overflow in lib/lz4/lz4_compress.c:294:9 > > So I did get the chacha20poly1305 ones, but they're hardly unique. > > If this new sanitizer is going to move forward, is there any sort of plan or > guide for how to update code to be compatible with it? Specifically considering > common situations where unsigned wraparound (which is defined behavior in C) can > be intentionally relied on, like calculating the distance from the next N-byte > boundary. What are the best practices now? Hi, yes, this is still under development. I tried to make it hard to enable accidentally (not via COMPILE_TEST, not UBSAN-default, etc), but we (still) don't have a way to disable configs for randconfigs. :( We're hoping to see Clang 21 with the more versatile Overflow Behavior Types: https://discourse.llvm.org/t/rfc-v2-clang-introduce-overflowbehaviortypes-for-wrapping-and-non-wrapping-arithmetic/86507 and our current testing is showing many fewer false positives. (Having run syzkaller for weeks now.) > Documentation/dev-tools/ubsan.rst says nothing about this and only mentions > "undefined behavior", which this is not. Right -- this will get extensive documentation before we move it out of its development phase. I'm not sure how to enforce "don't enable this unless you're developing the Overflow Behavior Types" with current Kconfig, given the randconfig gap... I have some memory of Arnd doing something special with his randconfigs to avoid these kinds of things, but I can't find it now. -Kees -- Kees Cook ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linus:master] [crypto] 40b9969796: UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c 2025-05-28 16:45 ` Kees Cook @ 2025-05-28 16:58 ` Arnd Bergmann 2025-05-28 17:15 ` Jann Horn 1 sibling, 0 replies; 6+ messages in thread From: Arnd Bergmann @ 2025-05-28 16:58 UTC (permalink / raw) To: Kees Cook, Eric Biggers, Justin Stitt Cc: linux-hardening, oe-lkp, kernel test robot, linux-kernel, Herbert Xu, linux-arm-kernel, loongarch, linux-s390, linux-crypto, kernel test robot, llvm On Wed, May 28, 2025, at 18:45, Kees Cook wrote: > On Tue, May 27, 2025 at 11:14:27PM -0700, Eric Biggers wrote: >> On Wed, May 28, 2025 at 01:15:05PM +0800, kernel test robot wrote: > I'm not sure how to enforce "don't enable this unless you're developing > the Overflow Behavior Types" with current Kconfig, given the randconfig > gap... I have some memory of Arnd doing something special with his > randconfigs to avoid these kinds of things, but I can't find it now. > The main thing I do on the randconfig builds to avoid obscure issues is to force CONFIG_COMPILE_TEST=y, but that only works for build testing, not actually running it. Arnd ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linus:master] [crypto] 40b9969796: UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c 2025-05-28 16:45 ` Kees Cook 2025-05-28 16:58 ` Arnd Bergmann @ 2025-05-28 17:15 ` Jann Horn 2025-05-28 17:41 ` Kees Cook 1 sibling, 1 reply; 6+ messages in thread From: Jann Horn @ 2025-05-28 17:15 UTC (permalink / raw) To: Kees Cook Cc: Eric Biggers, Justin Stitt, linux-hardening, oe-lkp, lkp, linux-kernel, Herbert Xu, linux-arm-kernel, loongarch, linux-s390, linux-crypto, kernel test robot, Arnd Bergmann, llvm, Masahiro Yamada, Nathan Chancellor, Nicolas Schier, linux-kbuild On Wed, May 28, 2025 at 6:46 PM Kees Cook <kees@kernel.org> wrote: > On Tue, May 27, 2025 at 11:14:27PM -0700, Eric Biggers wrote: > > If this new sanitizer is going to move forward, is there any sort of plan or > > guide for how to update code to be compatible with it? Specifically considering > > common situations where unsigned wraparound (which is defined behavior in C) can > > be intentionally relied on, like calculating the distance from the next N-byte > > boundary. What are the best practices now? > > Hi, yes, this is still under development. I tried to make it hard to > enable accidentally (not via COMPILE_TEST, not UBSAN-default, etc), but > we (still) don't have a way to disable configs for randconfigs. :( > > We're hoping to see Clang 21 with the more versatile Overflow Behavior Types: > https://discourse.llvm.org/t/rfc-v2-clang-introduce-overflowbehaviortypes-for-wrapping-and-non-wrapping-arithmetic/86507 > > and our current testing is showing many fewer false positives. (Having > run syzkaller for weeks now.) > > > Documentation/dev-tools/ubsan.rst says nothing about this and only mentions > > "undefined behavior", which this is not. > > Right -- this will get extensive documentation before we move it out of > its development phase. > > I'm not sure how to enforce "don't enable this unless you're developing > the Overflow Behavior Types" with current Kconfig, given the randconfig > gap... I have some memory of Arnd doing something special with his > randconfigs to avoid these kinds of things, but I can't find it now. You could depend on CONFIG_BROKEN, the canonical "if you enable this and stuff breaks, it's your fault" flag? Or if you want something even more explicit, maybe something like this would do the job, so that you have to set an environment variable for the kernel build to unlock the feature? (To be clear, I'm not fluent in kconfig, and this is almost certainly a terribly convoluted way of writing this - if you like the idea you should figure out the proper syntax.) config VERY_BROKEN def_bool $(success,sh -c 'echo $ENABLE_VERY_BROKEN_STUFF | grep "^y$"') config FOO depends on VERY_BROKEN ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [linus:master] [crypto] 40b9969796: UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c 2025-05-28 17:15 ` Jann Horn @ 2025-05-28 17:41 ` Kees Cook 0 siblings, 0 replies; 6+ messages in thread From: Kees Cook @ 2025-05-28 17:41 UTC (permalink / raw) To: Jann Horn Cc: Eric Biggers, Justin Stitt, linux-hardening, oe-lkp, lkp, linux-kernel, Herbert Xu, linux-arm-kernel, loongarch, linux-s390, linux-crypto, kernel test robot, Arnd Bergmann, llvm, Masahiro Yamada, Nathan Chancellor, Nicolas Schier, linux-kbuild On Wed, May 28, 2025 at 07:15:18PM +0200, Jann Horn wrote: > On Wed, May 28, 2025 at 6:46 PM Kees Cook <kees@kernel.org> wrote: > > On Tue, May 27, 2025 at 11:14:27PM -0700, Eric Biggers wrote: > > > If this new sanitizer is going to move forward, is there any sort of plan or > > > guide for how to update code to be compatible with it? Specifically considering > > > common situations where unsigned wraparound (which is defined behavior in C) can > > > be intentionally relied on, like calculating the distance from the next N-byte > > > boundary. What are the best practices now? > > > > Hi, yes, this is still under development. I tried to make it hard to > > enable accidentally (not via COMPILE_TEST, not UBSAN-default, etc), but > > we (still) don't have a way to disable configs for randconfigs. :( > > > > We're hoping to see Clang 21 with the more versatile Overflow Behavior Types: > > https://discourse.llvm.org/t/rfc-v2-clang-introduce-overflowbehaviortypes-for-wrapping-and-non-wrapping-arithmetic/86507 > > > > and our current testing is showing many fewer false positives. (Having > > run syzkaller for weeks now.) > > > > > Documentation/dev-tools/ubsan.rst says nothing about this and only mentions > > > "undefined behavior", which this is not. > > > > Right -- this will get extensive documentation before we move it out of > > its development phase. > > > > I'm not sure how to enforce "don't enable this unless you're developing > > the Overflow Behavior Types" with current Kconfig, given the randconfig > > gap... I have some memory of Arnd doing something special with his > > randconfigs to avoid these kinds of things, but I can't find it now. > > You could depend on CONFIG_BROKEN, the canonical "if you enable this > and stuff breaks, it's your fault" flag? Yeah. Talking with Justin out of band, he suggested the same. It's easier to carry a 1 line patch downstream while we're testing to enable this feature, so I'll send a patch to add CONFIG_BROKEN for now. -Kees -- Kees Cook ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-05-28 17:43 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-05-28 5:15 [linus:master] [crypto] 40b9969796: UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c kernel test robot 2025-05-28 6:14 ` Eric Biggers 2025-05-28 16:45 ` Kees Cook 2025-05-28 16:58 ` Arnd Bergmann 2025-05-28 17:15 ` Jann Horn 2025-05-28 17:41 ` Kees Cook
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).