linux-kernel - Re: CONFIG_KASAN triggers ASAN bug in GCC 13.3.0 and 14.1.0

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFULd4aCBMXcco_GdTYu9Zmc5A6+Z=J4XrsjLXWe1dydRD0oDQ@mail.gmail.com>
Date: Thu, 27 Feb 2025 13:30:58 +0100
From: Uros Bizjak <ubizjak@...il.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Matt Fleming <matt@...dmodwrite.com>, Jakub Jelinek <jakub@...hat.com>, 
	linux-kernel@...r.kernel.org, kernel-team@...udflare.com
Subject: Re: CONFIG_KASAN triggers ASAN bug in GCC 13.3.0 and 14.1.0

On Thu, Feb 27, 2025 at 1:22 PM Ingo Molnar <mingo@...nel.org> wrote:
>
>
> * Uros Bizjak <ubizjak@...il.com> wrote:
>
> > On Mon, Dec 16, 2024 at 5:20 PM Matt Fleming <matt@...dmodwrite.com> wrote:
> > >
> > > On Sat, Dec 14, 2024 at 1:17 AM Uros Bizjak <ubizjak@...il.com> wrote:
> > > >
> > > > Does your config include CONFIG_UBSAN_BOOL=y ?
> > >
> > > Yes, it does!
> > >
> > > > There is a rare interaction between CONFIG_KASAN and CONFIG_UBSAN_BOOL
> > > > (aka -fsanitize=bool), reported in [1] and fixed for gcc-14.2 in [2].
> > > >
> > > > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736#c42
> > > >
> > > > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172
> > > >
> > > > Otherwise, please attach your .config, and I'll look into this issue.
> > >
> > > Thanks. Disabling CONFIG_UBSAN_BOOL does indeed make the kernels boot again.
> > >
> > > Should CONFIG_UBSAN_BOOL have a dependency on GCC 14.4+ ?
> >
> > No, this is a very rare Oops that triggers only with gcc-14.1 version
> > and only when both KASAN and UBSAN are enabled. This is actually the
> > problem with sanitization of the percpu address when named address
> > spaces are enabled (IOW, sanitization of __seg_gs prefixed address).
> > UBSAN creates a temporary in memory, but forgets to copy memory tags,
> > including named address space qualifier from the original. Later ASAN
> > sanitizes this location as a normal variable (due to missing
> > qualifier), but actually should be disabled for __seg_gs prefixed
> > addresses.
> >
> > Your report is only *the second* since sanitizers were re-enabled with
> > named address spaces. gcc-14.2 that includes the fix is available
> > since August 2024, and since sanitizers are strictly development
> > tools, my proposed solution would be to simply upgrade the compiler to
> > gcc-14.2 release.
>
> So unless this is difficult to test for, it would be nice to have a
> compiler version cutoff for the feature. Especially if it's been
> reported twice already, chances are that a lot more people have
> experienced it already.
>
> The kernel build should avoid this known oops automatically.

The patch could be as simple as:

--cut here--
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 95ea2b4b95db..c94c37889917 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2370,7 +2370,7 @@ config CC_HAS_NAMED_AS
     depends on CC_IS_GCC

 config CC_HAS_NAMED_AS_FIXED_SANITIZERS
-    def_bool CC_IS_GCC && GCC_VERSION >= 130300
+    def_bool CC_IS_GCC && GCC_VERSION >= 140200

 config USE_X86_SEG_SUPPORT
     def_bool y
--cut here--

but it will disable all sanitizers for a very rare Oops that needs the
combination of CONFIG_KASAN and CONFIG_UBSAN_BOOL. The fix is
available in gcc-14.2, released in August 2024.

Uros.