CVE-2026-80730: ring-buffer: Fix crash passing ERR_PTR to kthread_stop()
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix crash passing ERRPTR to kthreadstop()
In testringbuffer()'s outfree cleanup loop, the check !rbthreads[cpu] only catches NULL entries and misses entries that hold an ERRPTR.
rbthreads[] is static, so unassigned slots are NULL. But when kthreadrunoncpu() fails for a cpu, it stores ERRPTR(-ENOMEM) (or -EINTR) in rbthreads[cpu] before the creation loop jumps to outfree. That entry is non-NULL, so the old !ptr check does not break, and the cleanup proceeds to call kthreadstop() on the ERRPTR. kthreadstop() then dereferences the bogus pointer, crashing the kernel during the lateinitcall self-test.
crash logs: BUG: kernel NULL pointer dereference, address: 000000000000001c Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 1 Comm: swapper/0 Not tainted 7.2.0-rc6-dirty #7 PREEMPT(lazy) RIP: 0010:kthreadstop+0x2e/0x220 RBX: fffffffffffffff4 CR2: 000000000000001c Call Trace: <TASK> testringbuffer+0x1ec/0x650 dooneinitcall+0x6c/0x2c0 kernelinitfreeable+0x21d/0x420 kernelinit+0x15/0x1c0 retfromfork+0x21b/0x320 </TASK> Kernel panic - not syncing: Fatal exception
Affected Software
Event History
Frequently Asked Questions
Under what conditions can this crash occur?
The crash occurs during the ring-buffer late_initcall self-test when kthread_run_on_cpu() fails for a CPU and leaves an ERR_PTR value in the rb_threads[] array. Cleanup then passes that error pointer to kthread_stop(), causing a kernel dereference and panic.
Is this reachable through normal runtime ring-buffer activity?
The provided information identifies the failure path as the late_initcall test_ringbuffer() self-test during kernel initialization. It does not describe a runtime or externally triggered path.
What failure conditions lead to the invalid thread pointer?
kthread_run_on_cpu() can fail with errors such as -ENOMEM or -EINTR. The affected cleanup check handles NULL array entries but not ERR_PTR entries produced by those failures.
How can an affected system be recognized?
Affected systems may panic during boot or initialization, with test_ringbuffer() and kthread_stop() in the call trace. The supplied crash example shows a NULL pointer dereference at kthread_stop() followed by "Kernel panic - not syncing: Fatal exception".