Re: CONFIG_KASAN triggers ASAN bug in GCC 13.3.0 and 14.1.0

[Ingo Molnar <mingo@kernel.org>]

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

> On Thu, Feb 27, 2025 at 1:46 PM Ingo Molnar <mingo@kernel.org> wrote:
> >
> >
> > * Uros Bizjak <ubizjak@gmail.com> wrote:
> >
> > > On Thu, Feb 27, 2025 at 1:22 PM Ingo Molnar <mingo@kernel.org> wrote:
> > > >
> > > >
> > > > * Uros Bizjak <ubizjak@gmail.com> wrote:
> > > >
> > > > > On Mon, Dec 16, 2024 at 5:20 PM Matt Fleming <matt@readmodwrite.com> wrote:
> > > > > >
> > > > > > On Sat, Dec 14, 2024 at 1:17 AM Uros Bizjak <ubizjak@gmail.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?
> 
> I am testing the attached patch that resolves the issue.

Thank you!

	Ingo