Look up another CVE · open CVE-2026-97409 in the interactive tracker
CVE-2026-97409
nvme-fc: Do not cancel requests in io target before it is initialized
Published 2026-09-24 (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-97409 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.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-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
A new nvme-fc controller in CONNECTING state sees admin request timeout schedules ctrl->ioerr_work to abort inflight requests. This ends up calling __nvme_fc_abort_outstanding_ios() which aborts requests in both admin and io tagsets. In case fc_ctrl->tag_set was not initialized we see the warning below. This is because ctrl.queue_count is initialized early in nvme_fc_alloc_ctrl(). nvme nvme0: NVME-FC{0}: starting error recovery Connectivity Loss INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe lpfc 0000:ab:00.0: queue 0 connect admin queue failed (-6). you didn't initialize this object before use? turning off the locking correctness validator. Workqueue: nvme-reset-wq nvme_fc_ctrl_ioerr_work [nvme_fc] Call Trace: <TASK> dump_stack_lvl+0x57/0x80 register_lock_class+0x567/0x580 __lock_acquire+0x330/0xb90 lock_acquire.part.0+0xad/0x210 blk_mq_tagset_busy_iter+0xf9/0xc00 __nvme_fc_abort_outstanding_ios+0x23f/0x320 [nvme_fc] nvme_fc_ctrl_ioerr_work+0x172/0x210 [nvme_fc] process_one_work+0x82c/0x1450 worker_thread+0x5ee/0xfd0 kthread+0x3a0/0x750 ret_from_fork+0x439/0x670 ret_from_fork_asm+0x1a/0x30 </TASK> Update the check in __nvme_fc_abort_outstanding_ios() confirm that io tagset was created before iterating over busy requests. Also make sure to cancel ctrl->ioerr_work before removing io tagset.
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/fc.c
- What this is
- NVM EXPRESS FC TRANSPORT DRIVERSMAINTAINERS section matched on drivers/nvme/host/fc.c · linux-nvme@lists.infradead.org · Supported
- Kernel module
- nvme_fc
Check it on the machine
grep -w CONFIG_NVME_FC /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_fcPrints 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 as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sid, bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_NVME_FC
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-24 (24 days ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.24%, higher than 14.2% 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 |
|---|---|---|
| 5.10 | 6.6.158 | 5488e2706c58 |
| 5.10 | 6.12.111 | da930308b4bc |
| 5.10 | 6.18.53 | dd39064d2948 |
| 5.10 | 7.2 | ee38469f8849 |
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:AAttack vector, adjacent network
- A rogue NVMe-FC target stalls or errors the admin-queue FCP from nvmf_connect_admin_queue() in nvme_fc_create_association(); nvme_fc_fcpio_done() queues ctrl->ioerr_work, and nvme_fc_ctrl_ioerr_work() -> nvme_fc_error_recovery() (CONNECTING) reaches the patched __nvme_fc_abort_outstanding_ios(). FC/FCoE is a non-routable SAN fabric, so Adjacent.
- AC:LAttack complexity, low
- nvme_fc_alloc_ctrl() sets queue_count > 1 before nvme_alloc_io_tag_set(), so CONNECTING has a zeroed embedded tag_set. The attacker creates that window by not completing the admin Connect FCP until nvme_fc_timeout()/nvme_fc_fcpio_done() runs; __nvme_fc_abort_outstanding_ios() then deterministically calls blk_mq_tagset_busy_iter(&ctrl->tag_set).
- PR:NPrivileges required, none
- The attacker is an unauthenticated NVMe-FC N_Port; the host transport does not authenticate the remote port (fabric zoning only). nvmf-autoconnect writes /dev/nvme-fabrics as root after FC_EVENT=nvmediscovery, so the fabric peer needs no host account or capability.
- UI:NUser interaction, none
- nvme_fc_register_remoteport() calls nvme_fc_signal_discovery_scan(), which emits KOBJ_CHANGE with FC_EVENT=nvmediscovery; nvmf-autoconnect and nvmefc-boot-connections then write /dev/nvme-fabrics with no interactive administrator. The admin-FCP stall is the attacker's own action.
- S:UScope, unchanged
- srcu_read_lock() on the uninitialized tags_srcu and the tag_set teardown UAF corrupt host kernel per-CPU data and blk-mq tag memory in the same kernel; no VM, IOMMU, or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- blk_mq_tagset_busy_iter() takes srcu_read_lock(&ctrl->tag_set.tags_srcu) on a kzalloc-zeroed tag_set, so __srcu_read_lock() this_cpu_inc()s a NULL srcu_ctrp. After nvme_alloc_io_tag_set(), nvme_fc_create_io_queues()'s error path also calls nvme_remove_io_tag_set() while nvme_reset_wq still iterates the live tag_set — a heap UAF.
- I:HIntegrity impact, high
- The NULL-srcu this_cpu_inc corrupts per-CPU words at offset 0 (x86 current_task is PER_CPU_CACHE_HOT). Concurrent blk_mq_free_tag_set() versus blk_mq_tagset_busy_iter() is a UAF of tag_set->tags and the SRCU sda; slab reuse of those objects yields a write/control-flow primitive.
- A:HAvailability impact, high
- The report is lockdep in blk_mq_tagset_busy_iter() from __nvme_fc_abort_outstanding_ios() on the zeroed tag_set. Without lockdep, this_cpu_inc of a NULL per-CPU pointer and the nvme_remove_io_tag_set() UAF oops or panic the host and take down the NVMe-FC storage path.