Linux Kernel CVE-2026-97409

Requires a system running the Linux kernel nvme-fc driver with actual Fibre Channel storage connectivity (e.g., lpfc HBA). The fault triggers only when a new nvme-fc controller is in CONNECTING state, the io tagset (fc_ctrl->tag_set) has not yet been initialized, and an admin request times out - typically due to FC connectivity loss during controller connect - causing ioerr_work to iterate busy requests over the uninitialized tagset. This is an internal transport/timing race, not attacker-supplied input; it cannot be triggered remotely or against a host without nvme-fc/FC hardware, which sharply limits real-world reach.

This is a Linux kernel nvme-fc (NVMe-over-Fibre-Channel) robustness bug in an error-recovery path, not an attacker-driven memory-corruption primitive. The scenario is deterministic and internal: a new controller in CONNECTING state hits an admin-request timeout (e.g., connectivity loss during connect), which schedules ctrl->ioerr_work → __nvme_fc_abort_outstanding_ios(), which iterates busy requests over the io tagset before that tagset was created (ctrl->queue_count is set early in nvme_fc_alloc_ctrl()). The observable symptom in the trace is a lockdep splat ('trying to register non-static key'), i.e., blk_mq_tagset_busy_iter() walking an uninitialized tagset - worst case a NULL/uninitialized deref crash, not disclosure. The NVD CVSS 8.8 AV:A/AC:L/PR:N/UI:N/C:H/I:H/A:H is grossly overstated: there is no adjacent-network attacker vector, no confidentiality or integrity impact, and the trigger is an FC-fabric/transport timing event during controller bring-up rather than crafted attacker input. No EPSS, no CISA KEV, and no public POC are present in the provided data. Real priority is LOW - this is a stability/lockdep fix, not an exploitable weakness. Note the conflict: CVSS asserts AV:A/PR:N/C:H/I:H but the description describes a local error-path race with no data impact - the vector should be verified/downgraded.

During nvme-fc controller connect, a Fibre Channel connectivity loss causes the admin queue connect to fail and the admin request to time out while the controller is still in CONNECTING state and the io tagset has not yet been allocated. The resulting ioerr_work iterates busy requests over the uninitialized io tagset, producing a lockdep warning and risking a crash on the host. No public exploit code exists and there is no attacker-controlled input - the condition is a transport/timing race, not a weaponizable vector.