CVE-2026-89972

The Linux kernel NVMe driver frees the namespace structure in the nvme_alloc_ns() error path (out_unlink_ns) after removing it from the head's siblings list with list_del_rcu(), but without first waiting for SRCU readers to finish. Because the NVMe multipath code iterates head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), a concurrent path lookup can still hold a pointer to the namespace when kfree(ns) runs, producing a use-after-free. The flaw is triggered when a namespace allocation or unlink error occurs while multipath readers are concurrently scanning paths, i.e., on systems using NVMe multipath such as dual-path local NVMe or NVMe-over-Fabrics. A successful race could yield kernel memory corruption leading to denial of service, and potentially privilege escalation in a best-case exploit. No public proof-of-concept, KEV listing, or in-the-wild exploitation is known, and triggering depends on local error conditions, so practical remote exploitation is unlikely despite the network-attack-vector CVSS score.

What to do: Update affected systems to a kernel that includes the upstream fix commit 'nvme: add missing SRCU grace period in error path' as soon as your distribution ships it, prioritizing hosts that use NVMe multipath (dual-controller NVMe SSDs, NVMe-oF with multiple paths). Check dmesg/journal for recurring NVMe namespace scan or unlink errors, which indicate the vulnerable error path can be reached. Given exploitation requires a local race with a namespace allocation failure, treat this as a stability and hardening fix rather than an urgent remote-threat patch.