CVE-2026-80730 in Linux
Summary
by MITRE • 09/03/2026
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix crash passing ERR_PTR to kthread_stop()
In test_ringbuffer()'s out_free cleanup loop, the check `!rb_threads[cpu]` only catches NULL entries and misses entries that
hold an ERR_PTR.
rb_threads[] is static, so unassigned slots are NULL. But when
kthread_run_on_cpu() fails for a cpu, it stores ERR_PTR(-ENOMEM) (or -EINTR) in rb_threads[cpu] before the creation loop jumps to out_free.
That entry is non-NULL, so the old `!ptr` check does not break, and the cleanup proceeds to call kthread_stop() on the ERR_PTR. kthread_stop() then dereferences the bogus pointer, crashing the kernel during the late_initcall 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:kthread_stop+0x2e/0x220 RBX: fffffffffffffff4 CR2: 000000000000001c Call Trace: <TASK> test_ringbuffer+0x1ec/0x650 do_one_initcall+0x6c/0x2c0 kernel_init_freeable+0x21d/0x420 kernel_init+0x15/0x1c0 ret_from_fork+0x21b/0x320 </TASK> Kernel panic - not syncing: Fatal exception
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The Linux kernel ring buffer subsystem contains a critical initialization flaw within the test_ringbuffer function that leads to a system crash during late_initcall self-tests. This vulnerability stems from improper error handling in the cleanup path when thread creation fails. Specifically, the rb_threads array is static and initialized with NULL values for unassigned slots. However, when kthread_run_on_cpu encounters an error such as -ENOMEM or -EINTR, it stores a negative ERR_PTR value into the corresponding slot before jumping to the out_free label. The existing cleanup logic relies on a simple null check using !rb_threads[cpu], which only identifies NULL pointers and fails to detect valid pointer values that encode error codes via ERR_PTR macros. Consequently, the loop proceeds to invoke kthread_stop() on these invalid pointers rather than skipping them or handling the error appropriately.
This logical oversight results in a kernel panic due to an attempt to dereference a bogus memory address. The crash occurs because kthread_stop expects either NULL or a valid task_struct pointer representing a running thread, but receives an ERR_PTR which is essentially a casted negative integer treated as a high-memory virtual address. When the function attempts to access fields within this non-existent structure, it triggers a general protection fault or null pointer dereference depending on the specific architecture and kernel configuration. The resulting crash halts the system during boot-up self-tests, preventing normal operation unless the ring buffer tests are disabled or patched.
From a classification perspective, this issue aligns with CWE-252 unchecked return value, as the code fails to properly validate the result of kthread_run_on_cpu before proceeding with cleanup operations that assume success. Additionally, it relates to CWE-476 NULL pointer dereference in its manifestation, although technically it is an invalid pointer dereference due to misinterpreted error codes rather than a true null reference. In terms of attack vectors and behavior mapping under the MITRE ATT&CK framework for Linux systems, this does not represent a direct exploitation vector but highlights weaknesses in defensive coding practices that could potentially be leveraged if similar patterns exist elsewhere with controllable inputs. The lack of robust error path validation is a common source of stability issues in kernel space where memory safety guarantees are less enforced than in user-space applications.
To mitigate this vulnerability, developers must update the cleanup loop to correctly identify and skip entries containing ERR_PTR values before calling kthread_stop(). This typically involves using IS_ERR macro checks alongside NULL checks to ensure that only valid thread pointers or explicitly null slots are processed during teardown. By implementing proper error code detection in resource deallocation routines, similar crashes can be prevented across other subsystems that follow analogous initialization and cleanup patterns. Maintaining strict adherence to kernel coding standards regarding error handling ensures system stability even under failure conditions during critical boot phases like late_initcall execution.