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

[Andrew Morton <akpm@linux-foundation.org>]

On Sun, 08 Nov 2026 19:58:37 -0800 syzbot <syzbot+73e34786d639a8eb1324@syzkaller.appspotmail.com> wrote:

> syzbot found the following issue on:
> 
> HEAD commit:    58c1eb84e977 arm64: sdei: Preserve the interrupted context..
> git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
> console output: https://syzkaller.appspot.com/x/log.txt?x=12d1d369580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=a58b6b4d667e7a61
> dashboard link: https://syzkaller.appspot.com/bug?extid=73e34786d639a8eb1324
> compiler:       Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
> userspace arch: arm64
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1255c1a1580000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/b1ec47537e12/disk-58c1eb84.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/3bca0c2b1169/vmlinux-58c1eb84.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/0a7c49594d5a/Image-58c1eb84.gz.xz
> 
> 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.
: 
: 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.