Hello,
I am reporting a possible RCU stall observed during fuzz testing on a
recent kernel.
=== Summary ===
The kernel reports an "rcu_preempt self-detected stall" while executing
kmemleak scanning code, apparently triggered via a debugfs write. The
stall happens inside a spin_unlock_irqrestore() path during kmemleak
object scanning.
This was observed under syzkaller-style fuzzing (syz-executor). I do not
currently have a minimal reproducer.
=== Environment ===
Kernel: 6.18.0 (locally built)
Config: PREEMPT(voluntary)
Arch: x86_64
Hardware: QEMU Standard PC (i440FX + PIIX)
CPU count: 4
Workload: syz-executor (fuzzing)
=== Observed behavior ===
Kernel reports an RCU stall:
INFO: rcu detected stall in corrupted
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 2-...!: (63 ticks this GP)
rcu: (t=263136 jiffies g=235149 q=10 ncpus=4)
The stall occurs on CPU 2 while running syz-executor.
=== Call trace (relevant part) ===
The stack trace points into kmemleak scanning code invoked via debugfs:
scan_object mm/kmemleak.c:1615
scan_gray_list mm/kmemleak.c:1648
kmemleak_scan mm/kmemleak.c:1800
kmemleak_write mm/kmemleak.c:2172
full_proxy_write fs/debugfs/file.c:388
vfs_write
ksys_write
do_syscall_64
The instruction pointer at the time of the stall is in:
_raw_spin_unlock_irqrestore
kernel/locking/spinlock.c:194
=== Additional observations ===
The system later shows journal corruption and systemd-journald being
restarted by the watchdog, possibly as a secondary effect.
syzkaller reports:
SYZFAIL: failed to recv rpc (errno 9: Bad file descriptor)
It is unclear whether this is directly related to the RCU stall or a
consequence of the system becoming unresponsive.
=== Reproducer ===
No standalone reproducer is currently available.
The issue was observed during fuzzing with syz-executor.
=== Expected behavior ===
No RCU stall should be reported during kmemleak scanning, even under
malformed or adversarial debugfs inputs.
=== Actual behavior ===
RCU reports a self-detected stall while executing kmemleak_scan.
=== Notes ===
This may indicate that kmemleak scanning holds preemption or interrupts
disabled for longer than expected under certain conditions, or that an
RCU read-side critical section is not being exited promptly.
Please let me know if additional information, kernel config details, or
further testing would be helpful.
Thanks for your time.
Reported-by:
Zhi Wang