[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202408150915.150AC9A3E@keescook>
Date: Thu, 15 Aug 2024 09:20:07 -0700
From: Kees Cook <kees@...nel.org>
To: Justin Stitt <justinstitt@...gle.com>
Cc: Breno Leitao <leitao@...ian.org>, elver@...gle.com,
andreyknvl@...il.com, ryabinin.a.a@...il.com,
kasan-dev@...glegroups.com, linux-hardening@...r.kernel.org,
axboe@...nel.dk, asml.silence@...il.com, netdev@...r.kernel.org
Subject: Re: UBSAN: annotation to skip sanitization in variable that will wrap
On Wed, Aug 14, 2024 at 02:05:49PM -0700, Justin Stitt wrote:
> Hi,
>
> On Wed, Aug 14, 2024 at 10:10 AM Breno Leitao <leitao@...ian.org> wrote:
> >
> > Hello,
> >
> > I am seeing some signed-integer-overflow in percpu reference counters.
>
> it is brave of you to enable this sanitizer :>)
>
> >
> > UBSAN: signed-integer-overflow in ./arch/arm64/include/asm/atomic_lse.h:204:1
> > -9223372036854775808 - 1 cannot be represented in type 's64' (aka 'long long')
> > Call trace:
> >
> > handle_overflow
> > __ubsan_handle_sub_overflow
> > percpu_ref_put_many
> > css_put
> > cgroup_sk_free
> > __sk_destruct
> > __sk_free
> > sk_free
> > unix_release_sock
> > unix_release
> > sock_close
> >
> > This overflow is probably happening in percpu_ref->percpu_ref_data->count.
> >
> > Looking at the code documentation, it seems that overflows are fine in
> > per-cpu values. The lib/percpu-refcount.c code comment says:
> >
> > * Note that the counter on a particular cpu can (and will) wrap - this
> > * is fine, when we go to shutdown the percpu counters will all sum to
> > * the correct value
> >
> > Is there a way to annotate the code to tell UBSAN that this overflow is
> > expected and it shouldn't be reported?
>
> Great question.
>
> 1) There exists some new-ish macros in overflow.h that perform
> wrapping arithmetic without triggering sanitizer splats -- check out
> the wrapping_* suite of macros.
>
> 2) I have a Clang attribute in the works [1] that would enable you to
> annotate expressions or types that are expected to wrap and will
> therefore silence arithmetic overflow/truncation sanitizers. If you
> think this could help make the kernel better then I'd appreciate a +1
> on that PR so it can get some more review from compiler people! Kees
> and I have some other Clang features in the works that will allow for
> better mitigation strategies for intended overflow in the kernel.
>
> 3) Kees can probably chime in with some other methods of getting the
> sanitizer to shush -- we've been doing some work together in this
> space. Also check out [2]
I haven't checked closely yet, but I *think* top 4 patches here[1]
(proposed here[2]) fix the atomics issues. The haven't landed due to
atomics maintainers wanting differing behavior from the compiler that
Justin is still working on (the "wraps" attribute alluded to above[3]).
-Kees
[1] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=dev/v6.8-rc2/signed-overflow-sanitizer
[2] https://lore.kernel.org/linux-hardening/20240424191225.work.780-kees@kernel.org/
[3] https://github.com/llvm/llvm-project/pull/86618
--
Kees Cook
Powered by blists - more mailing lists