Look up another CVE · open CVE-2026-98056 in the interactive tracker
CVE-2026-98056
nvme: remove stale namespaces by NSID range during scan
Published 2026-09-25 (24 days ago) by the Linux kernel CNA. Subsystem drivers/nvme. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-98056 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.7-1 | Update the kernel and reboot. Fixed in 7.2.7-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
nvme_scan_ns_list() drops the stale namespaces in each gap in the reported NSID list one NSID at a time. Every iteration calls nvme_find_get_ns() to look the namespace up and removes it if it is present. The loop runs once per NSID in the gap rather than once per namespace actually present. NSIDs are 32-bit, so a target with a sparse NSID space can make a single gap spin the loop billions of times with nothing to remove. watchdog: BUG: soft lockup - CPU#4 stuck for 26s! Workqueue: nvme-wq nvme_scan_work [nvme_core] RIP: 0010:__srcu_read_unlock+0xb/0x20 Call Trace: nvme_find_get_ns+0x7d/0xb0 [nvme_core] nvme_scan_ns_list+0xe8/0x280 [nvme_core] nvme_scan_work+0x18a/0x280 [nvme_core] process_one_work+0x197/0x380 worker_thread+0x2fe/0x410 kthread+0xe0/0x100 Rename nvme_remove_invalid_namespaces() to nvme_remove_nsid_range() and give it an open (start, end) NSID range. ctrl->namespaces is sorted by NSID, so the whole gap is dropped in a single walk that stops once end is reached. This bounds the work by the namespaces that are present instead of by the size of the gap.
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.
drivers/nvme/host/core.c
- What this is
- NVM EXPRESS DRIVERMAINTAINERS section matched on drivers/nvme/host/ · linux-nvme@lists.infradead.org · Supported
- Kernel module
- nvme_core
Check it on the machine
grep -w CONFIG_NVME_CORE /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.
lsmod | grep -w nvme_corePrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
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.12b
- b
- built in on some flavours, a module on others
- Build switch
- CONFIG_NVME_CORE
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-25 (24 days ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.60%, higher than 47.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/nvme
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.5 | 6.12.111 | c84ad7407fb1 |
| 4.5 | 6.18.53 | f56b2bb4b18b |
| 4.5 | 7.2.7 | 52200fc41a79 |
| 4.5 | 7.3 | 4ed7f3d7d435 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-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
- The gap is taken from the NSID list in the controller's Identify Active Namespace List (CNS 02h) reply. Over NVMe/TCP a remote target writes that reply, and nvme_scan_ns_list() uses it without checks. A list such as {1, 0xFFFFFFFE} makes the 'while (++prev < nsid) nvme_ns_remove_by_nsid()' loop run about 4 billion times.
- AC:LAttack complexity, low
- The target decides the NSID list, so the gap size is fully under its control and the spin happens every time. The target can also restart it on demand by sending a Namespace Attribute Changed AEN, which nvme_handle_aen_notice() turns into nvme_queue_scan().
- PR:NPrivileges required, none
- No host credentials are needed. The data is the target's own Identify reply, which nvme_scan_work() reads automatically whenever the controller goes live or an AEN arrives.
- UI:NUser interaction, none
- Once the host is connected, the target sets off the scan itself (at connect or via its own AEN). No user on the host has to do anything.
- S:UScope, unchanged
- The damage stays inside the host kernel's NVMe core scan worker. No VM, IOMMU or sandbox boundary is crossed.
- C:NConfidentiality impact, none
- The loop only looks up and removes namespaces with nvme_find_get_ns() and nvme_ns_remove(). Nothing is read out of bounds and no memory is disclosed.
- I:NIntegrity impact, none
- No memory is corrupted. The fix only bounds how much work the stale-namespace removal does, and the old code removed the right namespaces, just far too slowly.
- A:HAvailability impact, high
- nvme_scan_work pins a CPU for about 2^32 SRCU lookups with no cond_resched(), which causes a soft lockup (a panic if softlockup_panic is set) while holding ctrl->scan_lock. Repeated AENs keep it going, which stalls namespace management and controller teardown.