BUG: unable to handle kernel NULL pointer dereference in __put_partials in v6.14-rc4 kernel

[Strforexc yn]

Dear Maintainers, When using our customized Syzkaller to fuzz the
latest Linux kernel, the following crash was triggered.

Kernel commit: v6.14-rc4 (Commits on Feb 24, 2025)
Kernel Config : https://github.com/Strforexc/LinuxKernelbug/blob/main/.config
Kernel Log: attachment
Reproduce: attachment

I’ve encountered a NULL pointer dereference in the SLUB allocator on
Linux 6.14.0-rc4, causing a kernel panic. Here are the details:

A NULL pointer dereference occurs at address 0x11 in __put_partials
(mm/slub.c:3125), triggered during a slab flush operation. The
faulting instruction attempts to access slab->next from an invalid
pointer (0x1), crashing the kernel.

Possible Issues:
1.Corruption: A prior SLUB operation (e.g., allocation/freeing) may
have corrupted the partial slab list.
2. Race: A race between slab operations and flush_cpu_slab could leave
an invalid pointer, despite spin_lock_irqsave protection.

Context: Occurs during a routine slab flush via slub_flushwq, with no
modules loaded, pointing to a core SLUB bug

Could SLUB maintainers investigate? This might be:
1. A corruption in partial slab management (e.g., add_partial or discard_slab).
2. A concurrency issue in flush_cpu_slab scheduling. Suggested checks:
3. Validate partial_slab before entering the loop in __put_partials.
4. Audit SLUB list operations for race conditions.

Our knowledge of the kernel is somewhat limited, and we'd appreciate
it if you could determine if there is such an issue. If this issue
doesn't have an impact, please ignore it ☺.
If you fix this issue, please add the following tag to the commit:
Reported-by: Zhizhuo Tang <strforexctzzchange@xxxxxxxxxxx>, Jianzhou
Zhao <xnxc22xnxc22@xxxxxx>, Haoran Liu <cherest_san@xxxxxxx>

==================================================================
BUG: kernel NULL pointer dereference, address: 0000000000000011
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 800000004af87067 P4D 800000004af87067 PUD 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.14.0-rc4 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: slub_flushwq flush_cpu_slab
RIP: 0010:__put_partials+0x8a/0x190 mm/slub.c:3125
Code: 50 49 89 54 24 10 4d 89 7c 24 18 49 89 3f 4c 89 e7 e8 9a 98 ff
ff f0 80 48 01 02 48 85 db 0f 84 91 00 00 00 48 89 ef 49 89 dc <48> 8b
5b 10 49 8b 04 24 48 83 f8 ff 74 6b 49 8b 04 24 48 c1 e8 3a
RSP: 0018:ffffc900001afc20 EFLAGS: 00010282
RAX: 0000000000000046 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffff88802b638fa0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
R13: 0000000000000000 R14: ffff88804619d780 R15: ffff88801b496800
FS:  0000000000000000(0000) GS:ffff88802b600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000011 CR3: 0000000049314000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 process_one_work+0x109d/0x18c0 kernel/workqueue.c:3236
 process_scheduled_works kernel/workqueue.c:3317 [inline]
 worker_thread+0x677/0xe90 kernel/workqueue.c:3398
 kthread+0x3b3/0x760 kernel/kthread.c:464
 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:148
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 </TASK>
Modules linked in:
CR2: 0000000000000011
---[ end trace 0000000000000000 ]---
RIP: 0010:__put_partials+0x8a/0x190 mm/slub.c:3125
Code: 50 49 89 54 24 10 4d 89 7c 24 18 49 89 3f 4c 89 e7 e8 9a 98 ff
ff f0 80 48 01 02 48 85 db 0f 84 91 00 00 00 48 89 ef 49 89 dc <48> 8b
5b 10 49 8b 04 24 48 83 f8 ff 74 6b 49 8b 04 24 48 c1 e8 3a
RSP: 0018:ffffc900001afc20 EFLAGS: 00010282
RAX: 0000000000000046 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffff88802b638fa0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
R13: 0000000000000000 R14: ffff88804619d780 R15: ffff88801b496800
FS:  0000000000000000(0000) GS:ffff88802b600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000011 CR3: 0000000049314000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess):
   0: 50                   push   %rax
   1: 49 89 54 24 10       mov    %rdx,0x10(%r12)
   6: 4d 89 7c 24 18       mov    %r15,0x18(%r12)
   b: 49 89 3f             mov    %rdi,(%r15)
   e: 4c 89 e7             mov    %r12,%rdi
  11: e8 9a 98 ff ff       call   0xffff98b0
  16: f0 80 48 01 02       lock orb $0x2,0x1(%rax)
  1b: 48 85 db             test   %rbx,%rbx
  1e: 0f 84 91 00 00 00     je     0xb5
  24: 48 89 ef             mov    %rbp,%rdi
  27: 49 89 dc             mov    %rbx,%r12
* 2a: 48 8b 5b 10           mov    0x10(%rbx),%rbx <-- trapping instruction
  2e: 49 8b 04 24           mov    (%r12),%rax
  32: 48 83 f8 ff           cmp    $0xffffffffffffffff,%rax
  36: 74 6b                 je     0xa3
  38: 49 8b 04 24           mov    (%r12),%rax
  3c: 48 c1 e8 3a           shr    $0x3a,%rax

Thanks,
Zhizhuo Tang

Attachment: repro.cprog
Description: Binary data

Attachment: repro.log
Description: Binary data

Attachment: mount_0.gz
Description: GNU Zip compressed data

Attachment: log0
Description: Binary data