Look up another CVE · open CVE-2026-80589 in the interactive tracker
CVE-2026-80589
block: stop the timeout timer when releasing a never added disk
Published 2026-08-26 (2 months ago) by the Linux kernel CNA. Subsystem block. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-80589 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.105-1 | Update the kernel and reboot. Fixed in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.10-1 | Update the kernel and reboot. Fixed in 7.1.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.10-1 | Update the kernel and reboot. Fixed in 7.1.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
disk_release() undoes blk_mq_init_allocated_queue() for a disk whose probe failed before add_disk(), but it only calls blk_mq_exit_queue(). Nothing there stops q->timeout, and that timer rolls forward: it stays pending until it next expires, not until the last request completes. So if the driver issued any I/O before adding the disk, the request_queue is freed while still linked into a timer wheel bucket. Commit 6f8191fdf41d ("block: simplify disk shutdown") dropped the blk_cleanup_queue() call that used to stop it. __del_gendisk() and blk_mq_destroy_queue() still do; only the probe failure path lost it. nvme gets there because nvme_update_ns_info() submits Report Zones or FDP io-mgmt-recv on ns->queue before the disk is added, so a later failure - a concurrent reset setting NVME_CTRL_FROZEN, or device_add_disk() failing - lands in put_disk() with the timer armed: BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340 Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37 __timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621 blk_sync_queue+0x22/0x40 block/blk-core.c:222 nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362 nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264 Allocated by task 34: __blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462 nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146 Freed by task 0: blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254 rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857 The queue being synced there is ctrl->admin_q, only a victim sharing a timer wheel bucket with the freed queue's dangling entry; other runs tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work(). Failing nvme_alloc_ns() with a debug patch makes it deterministic: one leaked timer trips KASAN within seconds, while 1987 patched releases produced no splat. Stop the timer and the queue work items before blk_mq_exit_queue(), like blk_mq_destroy_queue() does. Found by FuzzNvme.
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.
block/genhd.c
- What this is
- BLOCK LAYERMAINTAINERS section matched on block/ · linux-block@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12y
- y
- built into the kernel image on every flavour - only a patch removes it
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 Debian linux-config packages
Signals
- Published
- 2026-08-26 (2 months ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.37%, higher than 29.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- block
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.0 | 6.1.184 | 6ae7364f68e6 |
| 6.0 | 6.6.153 | 6f06dbe5012c |
| 6.0 | 6.12.105 | 1a0ae4d50206 |
| 6.0 | 6.18.46 | bb03b56d1d75 |
| 6.0 | 7.1.10 | 93d620519d71 |
| 6.0 | 7.2 | 26cb8ebbfaf7 |
| 5.19.12 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- Exploitation reaches disk_release() via NVMe namespace probing that issues pre-add_disk I/O (FDP io-mgmt-recv, Report Zones) over NVMe-oF TCP/RDMA; a remote or storage-network peer can supply crafted responses during automatic scan/reconnect on cloud/datacenter initiators.
- AC:LAttack complexity, low
- An attacker controlling the NVMe endpoint can reliably time namespace enumeration I/O (arming q->timeout) with a concurrent probe failure (controller reset/NVME_CTRL_FROZEN or device_add_disk failure); FuzzNvme made this deterministic, and the attacker controls both sides of the race.
- PR:NPrivileges required, none
- No local account or capability is required on the victim host at exploitation time; once an NVMe fabric path exists, a remote/compromised target or storage-network attacker can trigger the probe-failure teardown without CAP_SYS_ADMIN, ioctl, or sysfs access.
- UI:NUser interaction, none
- The bug fires during automatic kernel namespace scan/reconnect and queue teardown on probe failure; no victim mount, login, or manual device interaction is required beyond normal background storage enumeration.
- S:UScope, unchanged
- Impact is kernel slab corruption and crashes within the host kernel block layer; it does not cross a VM, container, or IOMMU security boundary even though virtio_blk shares the same pre-add_disk probe pattern.
- C:HConfidentiality impact, high
- KASAN reports slab use-after-free with an 8-byte write in detach_if_pending on a freed request_queue whose timeout timer remains on the timer wheel; UAF of queue/timer structures enables arbitrary kernel memory disclosure primitives.
- I:HIntegrity impact, high
- The dangling timer wheel entry corrupts kernel heap metadata and can affect unrelated queues (e.g., ctrl->admin_q in the reported stack); UAF on request_queue/timer state is exploitable for arbitrary write and control-flow hijacking, not merely a crash.
- A:HAvailability impact, high
- Observed impact includes KASAN BUG/oops from timer deletion and queue sync on freed memory; leaked timers also trip in enqueue_timer(), __run_timers(), and blk_mq_timeout_work(), causing kernel panics and denial of service.