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

[1sh1ro <yangguikun19@qq.com>]

Hi,

I hit the same false positive and can add a data point that seems relevant for
the fix: it still reproduces on 7.3-rc5, i.e. after the CPUID rewrite that was
expected to take care of it.  The rewrite is in 7.3 -- get_cpu_cap() became
cpu_detect() -- and that is exactly the function my crashes interrupt.

Two occurrences, two kernels:

7.2.0-rc5:
  BUG: KASAN: wild-memory-access in do_raw_spin_lock+0x11c/0x270
  Write of size 4 at addr ff110000158860a8 by task swapper/0/0
   <IRQ> kasan_check_range; do_raw_spin_lock; handle_edge_irq+0x2e;
         __common_interrupt; common_interrupt
   RIP: get_cpu_cap+0x12f/0xc10
        identify_cpu+0x2f9  <- arch_cpu_finalize_init+0x58 <- start_kernel+0x373

7.3.0-rc5:
  BUG: KASAN: wild-memory-access in _raw_spin_lock+0x71/0xe0
  Write of size 4 at addr ff110000010ca8a8 by task swapper/0/0
   <IRQ> kasan_check_range; _raw_spin_lock; handle_edge_irq+0x2e;
         __common_interrupt; common_interrupt
   RIP: cpu_detect+0x20a/0x470
        identify_cpu+0x2df  <- arch_cpu_finalize_init+0x25 <- start_kernel+0x39c

The 5-level hypothesis matches what I measured on the 7.2-rc5 kernel:
page_offset_base is ff11000000000000, so the faulting address is physical
0x158860a8; /proc/iomem puts that immediately past the kernel image (Kernel bss
ends at 0x15577fff) and /proc/kpageflags reports SLAB for that PFN -- an
ordinary early-boot slab page (most likely the irq_desc itself), and KASAN
prints no "belongs to the object/cache" section for it.  So I agree this is a
false positive rather than a genuinely wild access.

Impact, in case it helps argue for the stable one-liner Borislav mentioned:
with panic_on_warn=1 (the syzkaller/syzbot default) this panics the booting
kernel, so fuzzing VMs fail to start; I currently work around it by booting
with panic_on_warn=0, which also loses real warnings.

Rate: rare and load-dependent -- 0 hits in 60 clean boots, but the fuzzer
(under load) saw it about 3 times in two weeks, so it is reproducible with
patience.

I filed it as <20261013015904.44144-kasan-early-boot@yangguikun19.qq.com> (both splats included) before finding this
thread.

Thanks,
1sh1ro