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

[Ihor Solodrai <ihor.solodrai@linux.dev>]

On 6/10/26 11:17 AM, sashiko-bot@kernel.org wrote:
> 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.

Correct. Setting USE_EARLY_PGTABLE_L5 only fixes the particular issue that I
stumbled on. AFAIU there may be a slight runtime performance hit when using
this flag, so we might not want to set it more widely.

I'll defer to KASAN maintainers to comment on this.

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

Yes, the underlying caveat that x86_capability is cleared within an 
interruptable window remains. Potentially any other interrupt handler that
checks for any other CPU capability may run into similar problem.

That said, LA57 and KASAN feel like a special case. And I don't see an obvious
way to fix this on identify_cpu() side. Disabling IRQ is clearly an overkill.

I'm very open to alternative solutions though, I am a tourist here.

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