public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>,
	Justin Stitt <justinstitt@google.com>
Cc: linux-hardening@vger.kernel.org, oe-lkp@lists.linux.dev,
	lkp@intel.com, linux-kernel@vger.kernel.org,
	Herbert Xu <herbert@gondor.apana.org.au>,
	linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
	linux-s390@vger.kernel.org, linux-crypto@vger.kernel.org,
	kernel test robot <oliver.sang@intel.com>,
	Arnd Bergmann <arnd@arndb.de>,
	llvm@lists.linux.dev
Subject: Re: [linus:master] [crypto]  40b9969796: UBSAN:unsigned-integer-overflow_in_lib/crypto/chacha20poly1305-selftest.c
Date: Wed, 28 May 2025 09:45:55 -0700	[thread overview]
Message-ID: <202505280937.6802F0F210@keescook> (raw)
In-Reply-To: <20250528061427.GA42911@sol>

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


  reply	other threads:[~2025-05-28 16:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2025-05-28 16:58     ` Arnd Bergmann
2025-05-28 17:15     ` Jann Horn
2025-05-28 17:41       ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202505280937.6802F0F210@keescook \
    --to=kees@kernel.org \
    --cc=arnd@arndb.de \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=justinstitt@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=loongarch@lists.linux.dev \
    --cc=oe-lkp@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox