CVE-2026-80916
CVE CVE-2026-80916EUVD EUVD-2026-75091Published 2026-09-09T16:13:14.000Z
What the advisory describes
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.
Source: EUVD (ENISA), in the words of the advisory.
Products the advisory names
These come from the advisory itself, not from any check we performed.
- Linux — Linux 5ff3b30ab57da82d8db4f14662a2858cabfbc2c0 <2eed77fdcb0cc48e8eccb2bcd4b7f2c6d650e84c; patch: 6.1.185; 5.8; patch: 7.3-rc1; 5ff3b30ab57da82d8db4f14662a2858cabfbc2c0 <22670d1552fe155822b2abf91f920925f7d067b4; 5ff3b30ab57da82d8db4f14662a2858cabfbc2c0 <f8c9a3ec36b4ee3d4701b9be08f40e7bfbf89761; patch: 0; patch: 6.12.106; patch: 7.2.1; patch: 6.6.154; 5ff3b30ab57da82d8db4f14662a2858cabfbc2c0 <e11f5b48c82703242a3be7a7ae4b4940b4cb4610; patch: 5.15.220; 5ff3b30ab57da82d8db4f14662a2858cabfbc2c0 <18799e858b407bf355383c9dd6c06477aa437134; patch: 7.1.11; 5ff3b30ab57da82d8db4f14662a2858cabfbc2c0 <5dc59fc959b2b5742985d7ef24bccd1868217dc2; 5ff3b30ab57da82d8db4f14662a2858cabfbc2c0 <8ed3ddf23d39bf5338406bd9f8863d44748cf6ce; patch: 5.10.269; patch: 6.18.47; 5ff3b30ab57da82d8db4f14662a2858cabfbc2c0 <a2fb8222cde23b0001812ed3acb7c0ea36dd94e2; 5ff3b30ab57da82d8db4f14662a2858cabfbc2c0 <ef7048d8a614c5f5a9b20513a5428101a744514e
The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.
Carried in the product catalogue
An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.
- Linux — Linux
Does this concern one of your customers?
This page cannot answer that — it does not know your estate. Whoever has recorded their environments gets the answer the morning after publication, together with a paragraph they can forward to the customer unedited.
Try it for 28 daysPatchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.