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

[Andrey Ryabinin]

Ihor Solodrai <ihor.solodrai@xxxxxxxxx> writes:

> On 6/10/26 10:56 AM, Ihor Solodrai wrote:
>>
>>  [...]
>>
>> diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
>> index 2b8e73f5f6a7..b5f430f2dbb6 100644
>> --- a/mm/kasan/generic.c
>> +++ b/mm/kasan/generic.c
>> @@ -9,6 +9,13 @@
>>   *        Andrey Konovalov <andreyknvl@xxxxxxxxx>
>>   */
>>
>> +/*
>> + * 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
>
> Hi everyone.
>
> Bumping the thread, as it's not clear how to proceed.
>
> From the discussion, we've got three approached to the bugfix:
>
>   1. USE_EARLY_PGTABLE_L5 in generic KASAN
>
>   This one is probably the simplest. We add USE_EARLY_PGTABLE_L5 to the
>   files that call addr_has_metadata(). It's KASAN / LA57 specific.
>
>   The downsides are a performance hit pointed out by Kiryl, and that
>   it's an arch-specific switch in generic KASAN.
>
>   2. local_irq_save/restore in identify_cpu() - Kiryl's suggestion
>
>   This looks like a better fix addressing the actual problem of cleared
>   capabilities being accessed from interrupts.
>
>   An open question for me is whether this fix is complete, and whether
>   the scope of irq_save/restore is right. We might also be ok with it
>   even if it's potentially incomplete.
>
>   3. Static key for LA57 in KASAN - sketched in the thread
>
>   This is essentially a bit better implementation of (1). Still KASAN /
>   LA57 specific.
>
> So my question to maintainers is what approach seems best?
> I am open to other suggestions if any.
>

AFAIU, this is not only KASAN's problem, at least in theory, so #2 seems
like the most appropriate solution.

If we decide to go with a KASAN-specific fix for some reason, Instead of
#1 or #3, I'd suggest using kasan_disable_current()/kasan_enable_current()
in identify_cpu(), the same way as as we already do for a similar
problem in apply_alternatives().

> So far this is mitigated on BPF CI with no5lvl boot param, but the bug
> is real, and I believe we should fix it in the kernel.
>
> Thanks!
>
>
>> +
>>  #include <linux/export.h>
>>  #include <linux/interrupt.h>
>>  #include <linux/init.h>