Description

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->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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-24T17:17:18.463Z",
  "pubdate": "2026-09-24T17:17:18.463Z",
  "executiveSummary": "A vulnerability exists in the NVMe-FC (Fibre Channel) implementation within the Linux kernel, specifically related to improper handling of controller initialization states.\nThe issue manifests as a NULL pointer dereference or invalid state access when the `nvme-fc` driver attempts to abort outstanding I/O requests before the associated I/O tagset has been fully initialized.\nThis vulnerability is triggered during error recovery processes, particularly when a controller in the 'CONNECTING' state encounters an admin request timeout, causing the driver to schedule `ctrl->ioerr_work` prematurely.\nImpacts include kernel panics, stack traces indicating locking validation failures, and system instability. While primarily a local availability issue, it disrupts storage connectivity, potentially impacting data integrity if the system crashes during critical I/O operations.\nExploitation does not require external network access but relies on the ability to trigger error recovery paths while the controller is in an intermediate state, effectively exploiting a race condition in the resource allocation lifecycle of the NVMe-FC transport.",
  "technicalDetails": "The vulnerability resides within the `nvme-fc` transport driver's handling of asynchronous error recovery mechanisms. The root cause is an invalid assumption regarding the lifecycle of the controller's tagsets during the initialization phase.\nIn the Linux kernel's `nvme-fc` subsystem, when a controller is in the 'CONNECTING' state, an administrative request timeout can trigger the execution of `nvme_fc_ctrl_ioerr_work`. This work function subsequently invokes `__nvme_fc_abort_outstanding_ios` to clear pending requests across all tagsets.\nThe critical flaw occurs because `ctrl.queue_count` is initialized early in the `nvme_fc_alloc_ctrl()` routine, before the actual I/O tagset is allocated or initialized. If `__nvme_fc_abort_outstanding_ios` is called while the controller is partially initialized, it attempts to iterate over the I/O tagset, which is not yet present in memory or remains unlinked.\nThis triggers a call to `blk_mq_tagset_busy_iter` on an uninitialized structure, leading to a lockdep warning or a kernel crash as the kernel attempts to acquire locks on invalid object headers. The call trace confirms the flow from `process_one_work` through `nvme_fc_ctrl_ioerr_work` directly into the iterator logic without prerequisite state validation.\nFurthermore, the absence of a synchronization mechanism to cancel `ctrl->ioerr_work` prior to the removal of the I/O tagset creates a temporal vulnerability. If a reset work item is queued but not executed until after the tagset is destroyed, the iterator attempts to access 'use-after-free' or NULL pointer memory regions.\nThe exploitation path follows these steps: 1) The controller initiates a connection attempt. 2) The admin queue request times out, signaling a transition to the error recovery work queue. 3) The `ioerr_work` handler blindly iterates over the tagsets based on early-initialized count variables. 4) The kernel detects an access attempt to an uninitialized object, triggering a diagnostic dump and subsequent service interruption or kernel panic."
}