Cloudanix VulnDB

CVE-2026-80916

None

CVSS

—

EPSS

0.2%

Published

Sep 9, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel on real-time systems could let data get overwritten during certain internal operations, potentially causing crashes in testing tools.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in KCOV remote state handling on PREEMPT_RT kernels where per-CPU temporary storage for saving/restoring KCOV state can be overwritten by nested softirq threads, causing permanent data corruption; also resolves potential NULL dereference, out-of-bounds access, and memory leaks during kcov_init if vmalloc_node fails.

Why it matters to the business

Systems running real-time Linux kernels may experience unexpected crashes or instability when KCOV is active, primarily affecting fuzzing, testing, and development workloads rather than production; 20 days since disclosure with no known exploitation increases urgency for kernel updates in affected environments.

How an attack unfolds

An attacker with the ability to trigger concurrent softirq preemption while a remote KCOV session is active on a PREEMPT_RT kernel could cause state corruption leading to kernel panic or undefined behavior; no named threat actors or campaigns are associated and the issue requires specific kernel configuration and local access.

How to fix it

Update to a Linux kernel version containing the fix that relocates temporary KCOV storage from per-CPU to per-thread areas while retaining the per-CPU lock; rebuild and deploy the patched kernel across all PREEMPT_RT deployments.

How to confirm the fix worked

Confirm the kernel source includes the per-thread storage change for KCOV remote state and that kcov_init properly handles vmalloc failures; test KCOV remote sessions under PREEMPT_RT with forced softirq nesting to verify no corruption occurs.

Typical attack path

  1. Gain local access to a PREEMPT_RT configured Linux system
  2. Enable or trigger KCOV remote start/stop operations
  3. Induce nested softirq preemption on the same CPU
  4. Trigger overwrite of per-CPU KCOV storage leading to state corruption
  5. Cause kernel instability, crash, or memory issues

How to detect it

Review kernel logs for oops, warnings, or panics referencing kcov_remote_start, kcov_init, or vmalloc failures; search for evidence of KCOV state corruption during softirq activity on PREEMPT_RT kernels.

What your security team should do

  • Prioritize kernel upgrade on all PREEMPT_RT systems within the next maintenance window
  • Audit development and CI environments using KCOV for exposure
  • Monitor for kernel oops or panics correlated with KCOV activity
  • Disable KCOV on production real-time systems until patched

The record

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.

Affected packages

Ecosystem Package Introduced Fixed