[PATCH] seqlock: Allow UBSAN to fail optimizing

[PATCH] seqlock: Allow UBSAN to fail optimizing

[Peter Zijlstra]

Very similar to commit:

  b94d45b6bbb4 ("seqlock: Allow KASAN to fail optimizing")

mark UBSAN as failing to optimize and not suitable for release builds.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601290910.uwScjRjc-lkp@intel.com/
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123873
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---

Debian folks, can you please remove CONFIG_UBSAN=y from your builds,
this is, per GCC devs, not a feature suitable for production!

diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index c00063dffba3..436f05bf5dd7 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -1259,14 +1259,14 @@ static __always_inline void __scoped_seqlock_cleanup(struct ss_tmp *sst)
 
 extern void __scoped_seqlock_invalid_target(void);
 
-#if (defined(CONFIG_CC_IS_GCC) && CONFIG_GCC_VERSION < 90000) || defined(CONFIG_KASAN)
+#if (defined(CONFIG_CC_IS_GCC) && CONFIG_GCC_VERSION < 90000) || defined(CONFIG_KASAN) || defined(CONFIG_UBSAN)
 /*
  * For some reason some GCC-8 architectures (nios2, alpha) have trouble
  * determining that the ss_done state is impossible in __scoped_seqlock_next()
  * below.
  *
- * Similarly KASAN is known to confuse compilers enough to break this. But we
- * don't care about code quality for KASAN builds anyway.
+ * Similarly *SAN is known to confuse compilers enough to break this. But we
+ * don't care about code quality for *SAN builds anyway.
  */
 static inline void __scoped_seqlock_bug(void) { }
 #else

Re: [PATCH] seqlock: Allow UBSAN to fail optimizing

[Salvatore Bonaccorso]

Hi Peter,

[Adding Kees as well]

On Thu, Jan 29, 2026 at 12:07:33PM +0100, Peter Zijlstra wrote:
> 
> Very similar to commit:
> 
>   b94d45b6bbb4 ("seqlock: Allow KASAN to fail optimizing")
> 
> mark UBSAN as failing to optimize and not suitable for release builds.
> 
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601290910.uwScjRjc-lkp@intel.com/
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123873
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> 
> Debian folks, can you please remove CONFIG_UBSAN=y from your builds,
> this is, per GCC devs, not a feature suitable for production!
> 
> diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
> index c00063dffba3..436f05bf5dd7 100644
> --- a/include/linux/seqlock.h
> +++ b/include/linux/seqlock.h
> @@ -1259,14 +1259,14 @@ static __always_inline void __scoped_seqlock_cleanup(struct ss_tmp *sst)
>  
>  extern void __scoped_seqlock_invalid_target(void);
>  
> -#if (defined(CONFIG_CC_IS_GCC) && CONFIG_GCC_VERSION < 90000) || defined(CONFIG_KASAN)
> +#if (defined(CONFIG_CC_IS_GCC) && CONFIG_GCC_VERSION < 90000) || defined(CONFIG_KASAN) || defined(CONFIG_UBSAN)
>  /*
>   * For some reason some GCC-8 architectures (nios2, alpha) have trouble
>   * determining that the ss_done state is impossible in __scoped_seqlock_next()
>   * below.
>   *
> - * Similarly KASAN is known to confuse compilers enough to break this. But we
> - * don't care about code quality for KASAN builds anyway.
> + * Similarly *SAN is known to confuse compilers enough to break this. But we
> + * don't care about code quality for *SAN builds anyway.
>   */
>  static inline void __scoped_seqlock_bug(void) { }
>  #else

Kees, Peter approached the Debian kernel list above to drop
CONFIG_UBSAN again, which, so I think we need to revert your
6cfadabfe015 ("Enable UBSAN_BOUNDS and UBSAN_SHIFT"):
https://salsa.debian.org/kernel-team/linux/-/commit/6cfadabfe015fa0d659fc8e3efd495cbcae3e44e

I have make a MR for our packaging for the change in
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1804

Regards,
Salvatore

Re: [PATCH] seqlock: Allow UBSAN to fail optimizing

[Kees Cook]

On Sat, Jan 31, 2026 at 10:39:42AM +0100, Salvatore Bonaccorso wrote:
> Kees, Peter approached the Debian kernel list above to drop
> CONFIG_UBSAN again, which, so I think we need to revert your
> 6cfadabfe015 ("Enable UBSAN_BOUNDS and UBSAN_SHIFT"):
> https://salsa.debian.org/kernel-team/linux/-/commit/6cfadabfe015fa0d659fc8e3efd495cbcae3e44e
> 
> I have make a MR for our packaging for the change in
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/1804

I am strongly opposed -- this undoes years of security flaw mitigation
work and leaves Debian (and only Debian!) exposed to trivial array index
overflows. The bounds sanitizer is the corner stone of memory safety
for C, and is not some "experimental" feature. GCC has a long history
of trouble with inlining, so this is not something unique to enabling
this feature.

I replied similarly to the PR. This would be a major mistake to disable.

-Kees

-- 
Kees Cook                                            @debian.org

Re: [PATCH] seqlock: Allow UBSAN to fail optimizing

[Peter Zijlstra]

On Sat, Jan 31, 2026 at 10:42:35AM -0800, Kees Cook wrote:
> On Sat, Jan 31, 2026 at 10:39:42AM +0100, Salvatore Bonaccorso wrote:
> > Kees, Peter approached the Debian kernel list above to drop
> > CONFIG_UBSAN again, which, so I think we need to revert your
> > 6cfadabfe015 ("Enable UBSAN_BOUNDS and UBSAN_SHIFT"):
> > https://salsa.debian.org/kernel-team/linux/-/commit/6cfadabfe015fa0d659fc8e3efd495cbcae3e44e
> > 
> > I have make a MR for our packaging for the change in
> > https://salsa.debian.org/kernel-team/linux/-/merge_requests/1804
> 
> I am strongly opposed -- this undoes years of security flaw mitigation
> work and leaves Debian (and only Debian!) exposed to trivial array index
> overflows. The bounds sanitizer is the corner stone of memory safety
> for C, and is not some "experimental" feature. GCC has a long history
> of trouble with inlining, so this is not something unique to enabling
> this feature.
> 
> I replied similarly to the PR. This would be a major mistake to disable.

Why the heck is bounds checking part of UBSAN? The simple fix here is to
get it out from CONFIG_UBSAN, so that CONFIG_UBSAN is debug only crap.

Notably, none of the UBSAN configs that tripped the optimization fail
even had bounds checking enabled.

Re: [PATCH] seqlock: Allow UBSAN to fail optimizing

[Kees Cook]

On Sun, Feb 01, 2026 at 12:47:41PM +0100, Peter Zijlstra wrote:
> On Sat, Jan 31, 2026 at 10:42:35AM -0800, Kees Cook wrote:
> > On Sat, Jan 31, 2026 at 10:39:42AM +0100, Salvatore Bonaccorso wrote:
> > > Kees, Peter approached the Debian kernel list above to drop
> > > CONFIG_UBSAN again, which, so I think we need to revert your
> > > 6cfadabfe015 ("Enable UBSAN_BOUNDS and UBSAN_SHIFT"):
> > > https://salsa.debian.org/kernel-team/linux/-/commit/6cfadabfe015fa0d659fc8e3efd495cbcae3e44e
> > > 
> > > I have make a MR for our packaging for the change in
> > > https://salsa.debian.org/kernel-team/linux/-/merge_requests/1804
> > 
> > I am strongly opposed -- this undoes years of security flaw mitigation
> > work and leaves Debian (and only Debian!) exposed to trivial array index
> > overflows. The bounds sanitizer is the corner stone of memory safety
> > for C, and is not some "experimental" feature. GCC has a long history
> > of trouble with inlining, so this is not something unique to enabling
> > this feature.
> > 
> > I replied similarly to the PR. This would be a major mistake to disable.
> 
> Why the heck is bounds checking part of UBSAN? The simple fix here is to
> get it out from CONFIG_UBSAN, so that CONFIG_UBSAN is debug only crap.

Out of bounds accesses are considered "undefined". *sigh*

But yes, now that we have the "transitional" kconfig symbols I can
trivially rename CONFIG_UBSAN_BOUNDS and remove its CONFIG_UBSAN
dependency.

> Notably, none of the UBSAN configs that tripped the optimization fail
> even had bounds checking enabled.

Which ones tripped it? KASAN (in software tagging mode) is usually the
heavy-weight one that considerably bloats code generation. I haven't
seen systemic problems with -fsanitize=bounds, and I thought the weird
cases (which confused the value range tracking) with -fsanitize=shift
got fixed back in GCC 12 (or maybe 13).

-Kees

-- 
Kees Cook

Re: [PATCH] seqlock: Allow UBSAN to fail optimizing

[Peter Zijlstra]

On Sun, Feb 01, 2026 at 07:39:46PM -0800, Kees Cook wrote:
> On Sun, Feb 01, 2026 at 12:47:41PM +0100, Peter Zijlstra wrote:
> > On Sat, Jan 31, 2026 at 10:42:35AM -0800, Kees Cook wrote:
> > > On Sat, Jan 31, 2026 at 10:39:42AM +0100, Salvatore Bonaccorso wrote:
> > > > Kees, Peter approached the Debian kernel list above to drop
> > > > CONFIG_UBSAN again, which, so I think we need to revert your
> > > > 6cfadabfe015 ("Enable UBSAN_BOUNDS and UBSAN_SHIFT"):
> > > > https://salsa.debian.org/kernel-team/linux/-/commit/6cfadabfe015fa0d659fc8e3efd495cbcae3e44e
> > > > 
> > > > I have make a MR for our packaging for the change in
> > > > https://salsa.debian.org/kernel-team/linux/-/merge_requests/1804
> > > 
> > > I am strongly opposed -- this undoes years of security flaw mitigation
> > > work and leaves Debian (and only Debian!) exposed to trivial array index
> > > overflows. The bounds sanitizer is the corner stone of memory safety
> > > for C, and is not some "experimental" feature. GCC has a long history
> > > of trouble with inlining, so this is not something unique to enabling
> > > this feature.
> > > 
> > > I replied similarly to the PR. This would be a major mistake to disable.
> > 
> > Why the heck is bounds checking part of UBSAN? The simple fix here is to
> > get it out from CONFIG_UBSAN, so that CONFIG_UBSAN is debug only crap.
> 
> Out of bounds accesses are considered "undefined". *sigh*

*sigh* indeed.

> But yes, now that we have the "transitional" kconfig symbols I can
> trivially rename CONFIG_UBSAN_BOUNDS and remove its CONFIG_UBSAN
> dependency.

That would be great; I can sit on this patch a while, its mostly build
robots and the like occasionally tripping this.

It would be good to have the compiler folks agree that bounds checking
is production code though :-)

> > Notably, none of the UBSAN configs that tripped the optimization fail
> > even had bounds checking enabled.
> 
> Which ones tripped it? KASAN (in software tagging mode) is usually the
> heavy-weight one that considerably bloats code generation. I haven't
> seen systemic problems with -fsanitize=bounds, and I thought the weird
> cases (which confused the value range tracking) with -fsanitize=shift
> got fixed back in GCC 12 (or maybe 13).

I'm not sure which one (I didn't care to find out, its debug nonsense
and nobody cares etc.. :-).

One has:

CONFIG_ARCH_HAS_UBSAN=y
CONFIG_UBSAN=y
CONFIG_UBSAN_TRAP=y
CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y
# CONFIG_UBSAN_BOUNDS is not set
# CONFIG_UBSAN_SHIFT is not set
CONFIG_UBSAN_DIV_ZERO=y
CONFIG_UBSAN_BOOL=y
CONFIG_UBSAN_ENUM=y

The other has:

CONFIG_ARCH_HAS_UBSAN=y
CONFIG_UBSAN=y
# CONFIG_UBSAN_TRAP is not set
CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y
# CONFIG_UBSAN_BOUNDS is not set
CONFIG_UBSAN_SHIFT=y
CONFIG_UBSAN_DIV_ZERO=y
# CONFIG_UBSAN_UNREACHABLE is not set
CONFIG_UBSAN_BOOL=y
# CONFIG_UBSAN_ENUM is not set
CONFIG_UBSAN_ALIGNMENT=y

The common ones are DIV_ZERO and BOOL.

Re: [PATCH] seqlock: Allow UBSAN to fail optimizing

[Kees Cook]

On February 2, 2026 12:29:39 AM PST, Peter Zijlstra <peterz@infradead.org> wrote:
>On Sun, Feb 01, 2026 at 07:39:46PM -0800, Kees Cook wrote:
>> On Sun, Feb 01, 2026 at 12:47:41PM +0100, Peter Zijlstra wrote:
>> > On Sat, Jan 31, 2026 at 10:42:35AM -0800, Kees Cook wrote:
>> > > On Sat, Jan 31, 2026 at 10:39:42AM +0100, Salvatore Bonaccorso wrote:
>> > > > Kees, Peter approached the Debian kernel list above to drop
>> > > > CONFIG_UBSAN again, which, so I think we need to revert your
>> > > > 6cfadabfe015 ("Enable UBSAN_BOUNDS and UBSAN_SHIFT"):
>> > > > https://salsa.debian.org/kernel-team/linux/-/commit/6cfadabfe015fa0d659fc8e3efd495cbcae3e44e
>> > > > 
>> > > > I have make a MR for our packaging for the change in
>> > > > https://salsa.debian.org/kernel-team/linux/-/merge_requests/1804
>> > > 
>> > > I am strongly opposed -- this undoes years of security flaw mitigation
>> > > work and leaves Debian (and only Debian!) exposed to trivial array index
>> > > overflows. The bounds sanitizer is the corner stone of memory safety
>> > > for C, and is not some "experimental" feature. GCC has a long history
>> > > of trouble with inlining, so this is not something unique to enabling
>> > > this feature.
>> > > 
>> > > I replied similarly to the PR. This would be a major mistake to disable.
>> > 
>> > Why the heck is bounds checking part of UBSAN? The simple fix here is to
>> > get it out from CONFIG_UBSAN, so that CONFIG_UBSAN is debug only crap.
>> 
>> Out of bounds accesses are considered "undefined". *sigh*
>
>*sigh* indeed.
>
>> But yes, now that we have the "transitional" kconfig symbols I can
>> trivially rename CONFIG_UBSAN_BOUNDS and remove its CONFIG_UBSAN
>> dependency.
>
>That would be great; I can sit on this patch a while, its mostly build
>robots and the like occasionally tripping this.
>
>It would be good to have the compiler folks agree that bounds checking
>is production code though :-)
>
>> > Notably, none of the UBSAN configs that tripped the optimization fail
>> > even had bounds checking enabled.
>> 
>> Which ones tripped it? KASAN (in software tagging mode) is usually the
>> heavy-weight one that considerably bloats code generation. I haven't
>> seen systemic problems with -fsanitize=bounds, and I thought the weird
>> cases (which confused the value range tracking) with -fsanitize=shift
>> got fixed back in GCC 12 (or maybe 13).
>
>I'm not sure which one (I didn't care to find out, its debug nonsense
>and nobody cares etc.. :-).
>
>One has:
>
>CONFIG_ARCH_HAS_UBSAN=y
>CONFIG_UBSAN=y
>CONFIG_UBSAN_TRAP=y
>CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y
># CONFIG_UBSAN_BOUNDS is not set
># CONFIG_UBSAN_SHIFT is not set
>CONFIG_UBSAN_DIV_ZERO=y
>CONFIG_UBSAN_BOOL=y
>CONFIG_UBSAN_ENUM=y
>
>The other has:
>
>CONFIG_ARCH_HAS_UBSAN=y
>CONFIG_UBSAN=y
># CONFIG_UBSAN_TRAP is not set
>CONFIG_CC_HAS_UBSAN_BOUNDS_STRICT=y
># CONFIG_UBSAN_BOUNDS is not set
>CONFIG_UBSAN_SHIFT=y
>CONFIG_UBSAN_DIV_ZERO=y
># CONFIG_UBSAN_UNREACHABLE is not set
>CONFIG_UBSAN_BOOL=y
># CONFIG_UBSAN_ENUM is not set
>CONFIG_UBSAN_ALIGNMENT=y
>
>The common ones are DIV_ZERO and BOOL.

DIV_ZERO is a known trouble-maker in Clang (though for its pathological behavior it needs CONFIG_UBSAN_TRAP). Perhaps we should drop it entirely?

-Kees

-- 
Kees Cook