[BUG] KASAN: wild-memory-access in handle_edge_irq while a CPU is in identify_cpu() during early boot

[1sh1ro]

Hi Andrey, Thomas,

fuzzing with syzkaller on KASAN kernels I hit a wild-memory-access report that
fires at early boot, while a CPU is running identify_cpu() and an edge IRQ
arrives.  With panic_on_warn=1 (the syzkaller/syzbot default) this panics the
booting kernel, i.e. it makes fuzzing VMs fail to start.  I have two
occurrences on two different kernels, and the address forensics suggest this
may be a KASAN-side issue rather than memory corruption -- I would appreciate
your opinion on which it is.

Occurrence 1 -- 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
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc5 #1 PREEMPT(full)
Call Trace:
 <IRQ>
 kasan_check_range+0x39/0x1c0
 do_raw_spin_lock+0x11c/0x270
 handle_edge_irq+0x2e/0x990
 __common_interrupt+0xd1/0x2f0
 common_interrupt+0xf0/0x110
 </IRQ>
 <TASK>
 asm_common_interrupt+0x26/0x40
RIP: 0010:get_cpu_cap+0x12f/0xc10
 identify_cpu+0x2f9/0x1e30 common.c:-1
 arch_cpu_finalize_init+0x58/0x3b0
 start_kernel+0x373/0x4d0
 x86_64_start_reservations+0x18/0x30
 </TASK>

Occurrence 2 -- 7.3.0-rc5 (same bug, cpu_detect() is the renamed get_cpu_cap())

BUG: KASAN: wild-memory-access in _raw_spin_lock+0x71/0xe0
Write of size 4 at addr ff110000010ca8a8 by task swapper/0/0
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.3.0-rc5 #2 PREEMPT(lazy)
Call Trace:
 <IRQ>
 kasan_check_range+0x39/0x1c0
 _raw_spin_lock+0x71/0xe0
 handle_edge_irq+0x2e/0x980
 __common_interrupt+0x7c/0x190
 common_interrupt+0xb8/0xd0
 </IRQ>
 <TASK>
 asm_common_interrupt+0x26/0x40
RIP: 0010:cpu_detect+0x20a/0x470
 identify_cpu+0x2df/0x1750 common.c:-1
 arch_cpu_finalize_init+0x25/0x3c0
 start_kernel+0x39c/0x490
 </TASK>

Why I suspect the shadow rather than memory corruption (7.2-rc5 case)

* page_offset_base is ff11000000000000 (5-level paging), so the address is
  physical 0x158860a8 = 360 MB.  /proc/iomem shows System RAM there, and it is
  immediately past the kernel image:

      01000000-0b33fec7 : Kernel code
      0b400000-0dafbfff : Kernel rodata
      0dc00000-1036a4ff : Kernel data
      1352a000-15577fff : Kernel bss
      0x158860a8        <- just past the image, early-boot allocation area

  /proc/kpageflags for that PFN (0x15886) reports SLAB, so it is a legitimate
  early slab page (most likely the irq_desc itself).
* The report contains no "The buggy address belongs to the object at ..." /
  "belongs to the cache ..." section -- KASAN could not resolve the address to
  any object, which is what the shadow looks like when it is not in a valid
  state for that region (early boot / embedded percpu / init shadow).
* It fires exactly while a CPU is in identify_cpu(), i.e. the earliest boot
  phase, and it is timing dependent: it is rare (0 hits in 30+30 clean boots
  under light load; the fuzzer saw it about 3 times in two weeks, i.e. under
  load), which points at a race rather than a deterministic bad pointer.

Environment

* syzkaller-style x86-64 kernels, KASAN_GENERIC + KASAN_INLINE (the 7.2 build
  also has KASAN_VMALLOC + DEBUG_VM; the 7.3 build has neither but does have
  RANDOMIZE_MEMORY), QEMU/KVM, 1-2 vCPUs, syzkaller's cmdline
  (numa=fake=2, page_owner=on, rcupdate.rcu_expedited=1, ...).

Reproducing

Boot the KASAN kernel with panic_on_warn=1 (or 0, and watch dmesg) with 1
vCPU, syzkaller-style cmdline, and repeat: it shows up every few tens of
boots, more often when the host is loaded.

Question

Is this a known limitation of KASAN for that early-boot region (shadow not yet
valid / embedded percpu / init memory), i.e. a false positive, or is the lock
access genuinely wild?  If it is a false positive, is there a supported way to
have early-boot code not trip it (we currently work around it by booting the
fuzzing VMs with panic_on_warn=0, which loses real warnings)?  Any pointer to
how to dump the shadow state for that address would also help me narrow it
down.

Thanks,
1sh1ro