Re: [syzbot] [mm?] [bluetooth?] BUG: unable to handle kernel NULL pointer dereference in __refill_objects_node

[Aleksandr Nogikh]

On Mon, Nov 9, 2026 at 5:28 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Sun, 08 Nov 2026 19:58:37 -0800 syzbot <syzbot+73e34786d639a8eb1324@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> > syzbot found the following issue on:
> > AI-generated root cause summary:
> > In mm/slub.c, __refill_objects_node() replenishes percpu sheaves by detaching a
> > freelist from a partial slab via get_freelist_nofreeze() and iterating through
> > the freelist pointers in a while (count && refilled < max) loop. Because the
> > loop condition only checks count and refilled rather than validating that object
> > is non-NULL, a prematurely terminated or corrupted freelist (where fewer objects
> > are linked in slab->freelist than the expected count = slab->objects -
> > slab->inuse) causes object to become NULL before count reaches zero. On the
> > subsequent iteration, get_freepointer() dereferences NULL + s->offset (offset
> > 0x400 for kmalloc-2k), resulting in an immediate kernel NULL pointer dereference
> > crash at address 0x0000000000000400.
> >
> > full analysis:  https://syzkaller.appspot.com/x/ai_root_cause?x=73e34786d639a8eb1324
>
> Thanks.
>
> : This looks like a bad syzkaller test, not a Bluetooth bug. The
> : reproducer runs as root, opens the active PCI device's resource0
> : (mode 0600), and maps its register space writable. It then places
> : syscall arguments inside that mapping. On this GCE VM,
> : 0000:00:02.0 is the NVMe controller; its BAR contains live control
> : registers and queue doorbells.

Yeah, it's unfortunately a known problem.. Sorry for the noise.

I've just sent a PR[1] to prevent syzkaller from manipulating those interfaces.
[1] https://github.com/google/syzkaller/pull/8111

> :
> : Both crash logs show NVMe completion ID and generation-counter
> : errors immediately before the SLUB fault. During minimization, the
> : same program produced crashes in several unrelated kernel paths,
> : including runs without the Bluetooth operation. This points to
> : disruption of the active NVMe device and subsequent corruption,
> : rather than a demonstrated SLUB or Bluetooth defect.
> :
> : The logs do not show the precise MMIO access or establish how the
> : freelist was damaged. Please rerun with the resource0 mapping
> : removed and the read buffer in ordinary memory. If the SLUB fault
> : persists without the NVMe errors, we can investigate it as a
> : separate kernel bug.
>