Linux kernel nvme-fc: use-after-free when an I/O error requeues ioerr_work during controller deletion

Impact

In nvme_fc_delete_ctrl(), cancel_work_sync() runs before nvme_fc_delete_association(), which waits for pending I/O to drain. An I/O error during that drain can requeue ->ioerr_work after the cancellation, so the work item is still live when the nvme_fc_ctrl object is freed - the reported symptom is list_del corruption and a kernel BUG in the workqueue path, taking the host down. The trigger is an NVMe-over-Fibre-Channel controller teardown that races with a fabric error, which is exactly what happens during SAN maintenance, path flapping or array failover. For operators this is a host-availability bug on nodes with FC-attached NVMe storage: the node panics and every job on it dies, and on a GPU node that is an unplanned eviction of whatever was training. There is no tenant-facing attack surface here - reaching it requires control over the storage fabric or the local ability to delete controllers, so treat it as a reliability fix rather than a tenant escape, and skip it entirely on fleets that do not use NVMe-FC.

Who can reach it

Not remotely reachable through tenant workloads. Requires either a fabric-side error condition during controller deletion or local privileged action that deletes an NVMe-FC controller, on a host with NVMe over Fibre Channel configured.

What to do

Take the stable kernel update that moves cancel_work_sync() after nvme_fc_delete_association(), via your distribution or the upstream stable commits. Rolling it out means draining the node and rebooting it to the new kernel. Priority should follow your storage topology: schedule it on FC-attached hosts ahead of SAN maintenance, and leave it to normal kernel cadence elsewhere, since hosts without NVMe-FC never load the affected path.

References

Related entries

• Linux kernel nvmet-fc: association deletion can be scheduled twice on forced port shutdownCVE-2025-40343 · Linux kernel nvmet-fc (NVMe-oF Fibre Channel target association teardown)Critical
• Linux kernel mlx5_core RX datapath (striding RQ + XDP multi-buffer): The mlx5 driver assumed an XDP program couldCVE-2025-40350 · Linux kernel mlx5_core RX datapath (striding RQ + XDP multi-buffer)Critical
• Xen: synthetic timer delivery assumes the SIM page is mapped, letting a guest crash the hostCVE-2025-58142 · Xen viridian enlightenments (SIM page, synthetic timer message delivery)Critical
• Xen: race in viridian reference TSC page mapping frees a page still live in the guest p2mCVE-2025-58143 · Xen viridian enlightenments (reference TSC page mapping race, p2m)Critical
• Linux kernel libceph: unchecked length from the wire allows out-of-bounds writes in cephx authCVE-2025-68284 · Linux kernel libceph (handle_auth_session_key length validation)Critical
• Linux kernel libceph: use-after-free racing a monmap or osdmap update during CephFS mountCVE-2025-68285 · Linux kernel libceph (have_mon_and_osd_map monmap/osdmap locking)Critical