Strix
63.4K

CVE-2026-80730

Unknown

Last modified

CVE-2026-80730 is a vulnerability of currently unknown severity. 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.

Description

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

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= 64ed3a049e3e81b801e7c5bb052416152443f585, < 51d78fad30dd9ae45721224103662bdbcf210096; >= 64ed3a049e3e81b801e7c5bb052416152443f585, < 93e7044b548a72022208595d2c1b188bb225ce83; >= 64ed3a049e3e81b801e7c5bb052416152443f585, < 8532983c312e8b875d7c9e440f8ee4674ea4b711; >= 64ed3a049e3e81b801e7c5bb052416152443f585, < 6dd7a06894d6d3dc84319bd0b7d1a7c27df9d902; >= 64ed3a049e3e81b801e7c5bb052416152443f585, < 3ea2fd344d93e3cf9503739b09fd702c0d8f8f0b; >= 64ed3a049e3e81b801e7c5bb052416152443f585, < 91542863abade2fd4f2b361991f5386ad9d19c8c
LinuxLinux5.17

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-80730?
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
How severe is CVE-2026-80730?
Severity scoring for CVE-2026-80730 is pending analysis.
How do I fix CVE-2026-80730?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

View all 2026CVEs →

Are you affected by CVE-2026-80730?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST