ZeroHour

CVE-2026-89974

niche

Double free of fabrics options in Linux kernel NVMe/FC (nvme-fc) driver

CVSS 3.1
7.5 high
EPSS
Published
()
Modified
AI analysis

CVE-2026-89974 is a double-free (observed as a slab use-after-free under KASAN) of the NVMe fabrics connection options structure in the Linux kernel's nvme-fc (NVMe over Fibre Channel) transport. It is triggered when nvme_add_ctrl() fails — for example when dev_set_name() cannot allocate memory under memory pressure or fault injection — so that nvme_fc_ctrl_free() and nvmf_create_ctrl() each free the same options object. An attacker able to reach the Fibre Channel fabric and induce controller-creation failures could corrupt kernel heap memory, with the CVSS vector indicating high confidentiality, integrity and availability impact, though exploitation requires adjacent-network access and high attack complexity. Only Linux systems using the nvme-fc transport (enterprise hosts and storage arrays in Fibre Channel SAN environments) are affected; the flaw was introduced by commit 1a9e218195a5 ('nvme: split device add from initialization'). No public proof-of-concept or in-the-wild exploitation is known, and the issue is not listed in CISA KEV.

What to do: Apply the upstream kernel patch, which reworks nvme-fc to derive fabrics-options ownership from rport->ctrl_list list membership as nvme-tcp/nvme-rdma/nvme-loop do, and update to a distribution kernel that includes this fix when available. In the meantime, restrict access to FC fabrics to trusted initiators and monitor kernel logs for nvme_fc controller-creation failures or KASAN 'slab-use-after-free in nvmf_free_options' reports.

Affected
Linux kernel (nvme-fc driver, NVMe over Fabrics Fibre Channel transport)
Estimated exposure
nichelikely tens of thousands of hosts or fewer (enterprise FC-SAN deployments; not internet-exposed) — nvme-fc is deployed almost exclusively in enterprise data centers with Fibre Channel SAN hardware, so the affected population is far below mass-market software, and the adjacent-network CVSS vector means no internet exposure.

Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.

Description

In the Linux kernel, the following vulnerability has been resolved: nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails nvmf_create_ctrl() owns the fabrics options and frees them whenever ->create_ctrl() returns an error, so a transport must not free them on its own error paths. nvme-fc tracks this by testing ctrl->ctrl.opts in nvme_fc_ctrl_free(), which requires nvme_fc_init_ctrl() to clear that pointer on every error exit. The coupling is implicit, and commit 1a9e218195a5 ("nvme: split device add from initialization") broke it by adding a second error exit. When nvme_add_ctrl() fails, nvme_fc_init_ctrl() jumps to out_put_ctrl:, past the "ctrl->ctrl.opts = NULL" that only sits on the fail_ctrl: path, so nvme_fc_ctrl_free() frees the options and nvmf_create_ctrl() frees them a second time: BUG: KASAN: slab-use-after-free in nvmf_free_options+0x30/0x190 nvmf_free_options+0x30/0x190 drivers/nvme/host/fabrics.c:1284 nvmf_create_ctrl drivers/nvme/host/fabrics.c:1374 [inline] Freed by task 5534: nvme_fc_ctrl_free drivers/nvme/host/fc.c:2374 [inline] nvme_fc_init_ctrl+0xe17/0x1450 drivers/nvme/host/fc.c:3605 nvme_add_ctrl() fails when dev_set_name() cannot allocate, so this is reachable under memory pressure or fault injection. Without KASAN the options are freed twice. Rather than clear the pointer on the second exit as well, derive ownership the way nvme-tcp, nvme-rdma and nvme-loop do, from list membership: their free_ctrl leaves the options alone unless the controller made it onto the transport list. The list cannot simply be populated on the success path as it is there. nvme-fc runs the initial connect synchronously via flush_delayed_work(), and the controller has to be reachable on rport->ctrl_list for the whole of it: nvme_fc_unregister_remoteport() needs to find it to signal connectivity loss, nvme_fc_match_disconn_ls() matches an incoming Disconnect Association LS against ctrl->association_id, which is only assigned during that window, nvme_fc_resume_controller() needs it on remoteport re-registration, and nvme_fc_existing_controller() uses it to reject a duplicate connect racing the one in flight. Keep the insertion where it is and add a fail_unlist: label, falling into fail_ctrl:, for the error paths that run after it. The earlier error paths never reach the insertion and keep using fail_ctrl: directly, so the list is only touched where the controller is actually on it. nvme_fc_ctrl_free() cannot use the plain "goto free_ctrl" the other transports use, because it still has to put_device(), release the rport reference and free the ida entry for resources taken before the insertion. Sample list_empty() under rport->lock instead. ctrl->ctrl.opts also stays valid for the whole teardown now. That is not the bug being fixed, but it removes some fragility around the old idiom: nvme_free_ctrl() calls nvme_auth_free() before ->free_ctrl(), and ctrl_max_dhchaps() dereferences ctrl->opts without a NULL check when ctrl->dhchap_ctxs is set, which nvme-fc permits since NVMF_ALLOWED_OPTS allows the dhchap options. The nvme sysfs attributes that dereference ctrl->opts, such as hostnqn and address, evaluate their is_visible() test once at device_add() time and stay readable until cdev_device_del().

Vector
CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

In the news

No ingested article mentions this CVE yet.