CVE-2026-97409: nvme-fc: Do not cancel requests in io target before it is initialized
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: Do not cancel requests in io target before it is initialized
A new nvme-fc controller in CONNECTING state sees admin request timeout schedules ctrl->ioerrwork to abort inflight requests. This ends up calling nvmefcabortoutstandingios() which aborts requests in both admin and io tagsets. In case fcctrl->tagset was not initialized we see the warning below. This is because ctrl.queuecount is initialized early in nvmefcallocctrl().
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 nvmefcctrlioerrwork [nvmefc] Call Trace: <TASK> dumpstacklvl+0x57/0x80 registerlockclass+0x567/0x580 lockacquire+0x330/0xb90 lockacquire.part.0+0xad/0x210 blkmqtagsetbusyiter+0xf9/0xc00 nvmefcabortoutstandingios+0x23f/0x320 [nvmefc] nvmefcctrlioerrwork+0x172/0x210 [nvmefc] processonework+0x82c/0x1450 workerthread+0x5ee/0xfd0 kthread+0x3a0/0x750 retfromfork+0x439/0x670 retfromforkasm+0x1a/0x30 </TASK>
Update the check in nvmefcabortoutstandingios() confirm that io tagset was created before iterating over busy requests. Also make sure to cancel ctrl->ioerrwork before removing io tagset.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In nvme-fc, do not cancel requests in the I/O target before it is initialized; ensure the I/O tagset is initialized before iterating over busy requests, and cancel ctrl->ioerr_work before removing the I/O tagset.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel NVMe over Fibre Channel (nvme-fc) driver can encounter it during creation of a new NVMe-FC controller. The described path involves a controller still in CONNECTING state whose admin request times out before the I/O tag set is initialized.
What conditions trigger the problem?
An admin-queue connection failure or timeout can schedule controller error recovery. That recovery attempts to abort outstanding requests in both the admin and I/O tag sets, including the uninitialized I/O tag set.
How can I recognize that this issue has occurred?
Kernel logs may show NVME-FC connectivity-loss error recovery and a lockdep warning about registering a non-static key or using an object before initialization. The stack trace includes nvme_fc_ctrl_ioerr_work and __nvme_fc_abort_outstanding_ios.