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: <Z8BekITYkuc4F4b1@gmail.com>
Date: Thu, 27 Feb 2025 13:46:08 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Uros Bizjak <ubizjak@...il.com>
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


* Uros Bizjak <ubizjak@...il.com> wrote:

> 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.

Can we not limit the version quirk to KASAN && UBSAN_BOOL?

> The fix is available in gcc-14.2, released in August 2024.

And this is a contradictory argument: if the fix is so available then 
it shouldn't really matter whether we have to quirk or not? Everyone 
should have the fix already and the quirk shouldn't affect them, right?

Thanks,

	Ingo