Re: [PATCH v1] kasan: Fix false-positive wild-memory-access on x86 under 5-level paging

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] Incomplete fix and architectural layering violation via x86-specific macro in generic KASAN code.

Pre-existing issues:
- [High] Unhandled root cause: CPU feature flags are non-atomically cleared while interrupts are enabled.
--

commit 5a28adbdf7cd811d1903c7692ad3799adc4606f3
Author: Ihor Solodrai <ihor.solodrai@linux.dev>

kasan: Fix false-positive wild-memory-access on x86 under 5-level paging

This commit attempts to fix a flaky false-positive KASAN splat on x86_64
with 5-level paging. It addresses a race where the LA57 CPU feature is
temporarily cleared during boot by defining USE_EARLY_PGTABLE_L5 in the
generic KASAN code.

> diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> index 2b8e73f5f6a70..b5f430f2dbb68 100644
> --- a/mm/kasan/generic.c
> +++ b/mm/kasan/generic.c
> @@ -9,6 +9,13 @@
>   *        Andrey Konovalov <andreyknvl@gmail.com>
>   */
>  
> +/*
> + * check_region_inline() and addr_has_metadata() can run very early.
> + * For example, in an interrupt taken while identify_cpu() has the CPU
> + * capability bits temporarily cleared.
> + */
> +#define USE_EARLY_PGTABLE_L5

[Severity: Medium]
Is it appropriate to place the x86-specific USE_EARLY_PGTABLE_L5 macro in
the generic KASAN code?

Since this macro is only defined locally in generic.c, other generic KASAN
files like mm/kasan/report.c remain unaware of it.

If a genuine KASAN bug occurs during the race window, wouldn't print_report()
miscalculate the shadow memory addresses:

mm/kasan/report.c:print_report() {
    ...
    if (addr_has_metadata(addr)) {
    ...
}

and fail to print the memory metadata because it uses the 4-level paging
start address instead of the 5-level one?

[ ... ]

> The root cause is in generic KASAN not seeing
> cpu_feature_enabled(X86_FEATURE_LA57) set, because the bit is cleared
> in identify_cpu() when the offending interrupt happens [1]:
> 
>   memset(&c->x86_capability, 0, ...);   /* clears X86_FEATURE_LA57 */
>   ...
>   get_cpu_cap(c);                       /* re-reads CPUID, restores it */

[Severity: High]
This is a pre-existing issue, but does this approach leave the underlying
race condition unhandled?

In arch/x86/kernel/cpu/common.c:identify_cpu(), boot_cpu_data.x86_capability
is cleared non-atomically while local interrupts are still enabled. This
can occur because arch_cpu_finalize_init() runs after local_irq_enable().

Because alternative instructions have not yet been patched at this point in
the boot sequence, cpu_feature_enabled() dynamically checks
boot_cpu_data.x86_capability.

Could any interrupt handler that fires during this window and checks a CPU
feature spuriously see it as disabled, potentially causing core subsystems
to execute incorrect fallback paths? 

Would it be safer to disable local interrupts during the boot_cpu_data
initialization in identify_cpu() instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610175651.647515-1-ihor.solodrai@linux.dev?part=1