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

From: Ihor Solodrai

Date: Wed Jun 17 2026 - 18:14:02 EST


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.

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>