CVE-2026-80916 in Linux
Summary
by MITRE • 09/09/2026
In the Linux kernel, the following vulnerability has been resolved:
kcov: fix data corruption and race conditions on PREEMPT_RT
syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the temporary storage used for saving/restoring remote KCOV state is currently allocated as the per-CPU area.
On PREEMPT_RT kernels, softirq handlers run as preemptible task threads (e.g., ksoftirqd). If a softirq context preempts a task running a remote KCOV session, it safely saves the task's state into the per-CPU area. However, if that softirq thread is subsequently preempted by a higher- priority softirq thread on the same CPU, the second softirq will overwrite the same per-CPU area, permanently destroying the original task's KCOV state.
Fix this data corruption by moving the temporary storage from the per-CPU area to the per-thread area. Since each softirq thread now owns its own task context, nested softirq preemption no longer causes data overwrites.
Note that while the temporary storage is now on a per-thread basis, the per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that kcov_remote_start() and kcov_remote_stop() operate atomically without racing against asynchronous interrupts that manipulate the current task's KCOV state.
It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init() has already called panic() before returning NULL, for there will be no OOM-killable userspace processes when __init function of built-in module runs. But this patch also fixes crashing the kernel when vmalloc_node() in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in
(1) doing vmalloc() in kcov_remote_start() despite !in_task() context
(2) out-of-array-bounds access if (1) succeeded but kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE
(3) always leak memory allocated by (1), eventually killing all OOM-killable userspace processes
problems.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/09/2026
The Linux kernel's Kernel Coverage instrumentation, known as KCOV, is a critical subsystem used for fuzzing and security research to track code execution paths. A significant vulnerability affecting PREEMPT_RT kernels involves data corruption and race conditions within the remote KCOV state management mechanism. The root cause lies in the allocation strategy for temporary storage used during save and restore operations of this state. Previously, this storage was allocated as a per-CPU area, which assumes exclusive access or safe preemption handling that does not hold under real-time scheduling constraints. On PREEMPT_RT kernels, softirq handlers execute as preemptible task threads rather than in hard interrupt context. This architectural shift introduces complex preemption scenarios where the atomicity of state preservation is compromised if not handled with thread-local isolation.
The operational flaw manifests when a softirq handler running on a CPU saves the KCOV state of a preempted user-space or kernel task into the shared per-CPU buffer. If this saving softirq thread is subsequently preempted by another higher-priority softirq thread on the same CPU, the second interrupt context will overwrite the same per-CPU memory location with its own temporary data. This overwrites and permanently destroys the original task's KCOV state before it can be restored upon resumption of the lower-priority task. This race condition leads to corrupted coverage data, which undermines the reliability of fuzzing campaigns that depend on accurate execution path tracking. Furthermore, such corruption can lead to undefined behavior in subsequent analysis tools or debugging sessions relying on this instrumentation.
The technical resolution involves migrating the temporary storage from a per-CPU scope to a per-thread scope. By allocating memory within the task context itself, each softirq thread maintains its own isolated state buffer. This change ensures that nested preemptions among softirq threads do not result in data overwrites because each executing context operates on distinct memory regions allocated for its specific task structure. However, this architectural shift necessitates careful retention of synchronization primitives. Specifically, the per-CPU kcov_percpu_data.lock must remain in place to ensure atomicity between kcov_remote_start and kcov_remote_stop operations. This lock prevents races against asynchronous interrupts that might manipulate the current task's KCOV state concurrently with these remote start-stop sequences, thereby preserving data integrity during context switches.
Beyond the primary race condition, the patch addresses critical initialization vulnerabilities related to memory allocation failures in kcov_init. The function vmalloc_node is used to allocate resources for per-CPU irq_area structures. In built-in modules or early boot stages where no OOM-killable userspace processes exist, a failure of this allocation could previously trigger a kernel panic due to the lack of fallback mechanisms. More dangerously, if kcov_init failed silently by leaving the per-CPU irq_area pointer as NULL while proceeding with initialization, subsequent calls to kcov_remote_start would encounter null-pointer dereferences or invalid memory accesses. Specifically, attempting vmalloc in an atomic context where !in_task() is true violates kernel locking rules and can lead to deadlocks or crashes.
If the allocation within kcov_remote_start were to succeed despite these flawed conditions, it could result in out-of-array-bounds access if the remote_size configuration parameter was smaller than CONFIG_KCOV_IRQ_AREA_SIZE. This memory safety violation allows for potential information disclosure or privilege escalation depending on what data resides adjacent to the allocated buffer. Additionally, failed allocations that do not properly clean up lead to persistent memory leaks. Over time, these leaked kernel pages can exhaust available physical memory resources, eventually causing system-wide instability by preventing legitimate OOM-killable processes from allocating necessary memory, effectively leading to a denial of service condition for user-space applications even if the core kernel remains operational.
From a classification perspective, this vulnerability aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, specifically regarding race conditions in multi-threaded environments involving real-time preemption models. The data corruption aspect relates to CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer, particularly when out-of-bounds accesses occur due to misconfigured sizes or null pointer dereferences leading to invalid memory operations. In terms of MITRE ATT&CK mapping for Linux systems, this falls under Tactic TA0005: Defense Evasion and potentially TA0004: Privilege Escalation if the memory corruption allows an attacker to overwrite critical kernel structures via crafted inputs that trigger these race conditions or allocation failures during fuzzing activities.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that restructures KCOV state storage to be thread-local rather than CPU-local for remote operations. System administrators and developers utilizing PREEMPT_RT kernels must ensure their systems are updated with this fix to prevent data corruption in security instrumentation tools. For environments where real-time performance is not strictly required, disabling PREEMPT_RT features may reduce the attack surface related to softirq preemption races, though this sacrifices latency guarantees. Additionally, rigorous testing of KCOV configurations should include stress tests that simulate high-frequency context switches and allocation failures to verify that memory leaks are properly handled and that null-pointer checks prevent crashes during initialization phases. Ensuring robust error handling in vmalloc_node calls within init functions is also crucial to maintain system stability under resource-constrained conditions.