CVE-2026-80916

What the bug is

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.

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

include/linux/sched.h
kernel/kcov.c
lib/Kconfig.debug

What this is

SCHEDULERMAINTAINERS section matched on include/linux/sched.h · linux-kernel@vger.kernel.org · Maintained

Kernel module

none to look for. The file would have gone into kcov, and Debian does not compile it into that module, so finding kcov in lsmod would say nothing about this CVE.

Check it on the machine

grep -w CONFIG_KCOV /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian does not build this code. In 5 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.

• bookworm, trixie, forky, sid, bookworm · linux-6.12n

n

not enabled on any flavour - this release does not build the code

Build switch

CONFIG_KCOV

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-09-09 (39 days ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.18%, higher than 7.2% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

include/linux

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
5.8	5.10.269	ef7048d8a614
5.8	5.15.220	8ed3ddf23d39
5.8	6.1.185	5dc59fc959b2
5.8	6.6.154	a2fb8222cde2
5.8	6.12.106	18799e858b40
5.8	6.18.47	e11f5b48c827
5.8	7.1.11	22670d1552fe
5.8	7.2.1	f8c9a3ec36b4
5.8	7.3	2eed77fdcb0c

Debian advisories