# CVE-2026-80916: kcov: fix data corruption and race conditions on PREEMPT_RT

> A race condition in the Linux kernel's KCOV subsystem on PREEMPT_RT kernels allows data corruption and potential denial of service via memory leaks.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 9 Sep 2026
- **Updated:** 19 Oct 2026
- **Also known as:** AZL-99968, BELL-CVE-2026-80916, DEBIAN-CVE-2026-80916, GHSA-cjj8-h3vv-gx8r, UBUNTU-CVE-2026-80916

## What is CVE-2026-80916?

CVE-2026-80916 is a vulnerability in Linux, published on 9 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

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.

## Which versions are affected by CVE-2026-80916?


## How do I fix CVE-2026-80916?

Apply the vendor's patch.

## Is CVE-2026-80916 being exploited?

There is no known exploitation of CVE-2026-80916 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-80916 and fix it if it is affected.

What it is: CVE-2026-80916 is a vulnerability in Linux, published on 9 Sep 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-80916 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-80916/ (Markdown: https://insights.sbomify.com/CVE-2026-80916/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-80916
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-80916
- OSV: https://osv.dev/vulnerability/CVE-2026-80916

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-80916/
Summaries are generated and may contain mistakes; the official description above is the record.