CVE-2026-89972: Linux Kernel Use-After-Free Vulnerability

CVE-2026-89972 Overview

CVE-2026-89972 is a use-after-free vulnerability in the Linux kernel's Non-Volatile Memory Express (NVMe) subsystem. The flaw resides in the nvme_alloc_ns() error path at the out_unlink_ns label. When namespace allocation fails, the code removes the namespace from the head siblings list using list_del_rcu(&ns->siblings) but omits the required Sleepable Read-Copy-Update (SRCU) grace period before freeing the namespace structure. Multipath code paths iterate head->list under srcu_read_lock(), allowing a concurrent reader to retain a reference to freed memory.

Critical Impact
Concurrent SRCU readers in nvme_find_path() and nvme_mpath_revalidate_paths() can dereference freed namespace memory, leading to kernel memory corruption.

Affected Products

Linux kernel NVMe driver (drivers/nvme/host/core.c)
Systems using NVMe multipath configurations
Distributions shipping affected upstream kernel versions prior to the referenced stable commits

Discovery Timeline

2026-09-16 - CVE-2026-89972 published to the National Vulnerability Database (NVD)
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-89972

Vulnerability Analysis

The vulnerability is a use-after-free condition in the NVMe host driver triggered by a race between the namespace allocation error path and multipath readers. When nvme_alloc_ns() encounters an error after linking the namespace into the head siblings list, control transfers to the out_unlink_ns label. That path calls list_del_rcu(&ns->siblings) to unlink the namespace, then proceeds to free the ns structure with kfree(ns).

The NVMe multipath subsystem walks head->list while holding an SRCU read-side lock. Both nvme_find_path() and nvme_mpath_revalidate_paths() operate under srcu_read_lock(&head->srcu). A reader that entered the critical section before list_del_rcu() can still hold a pointer to the removed namespace after it has been freed, resulting in dereferences of released kernel memory.

The normal removal path in nvme_ns_remove() handles this correctly by calling synchronize_srcu(&ns->head->srcu) after the list removal, which blocks until all pre-existing SRCU readers exit their critical sections. The error path omitted this grace period. The fix adds the matching synchronize_srcu() call to the error path so the namespace is only freed after concurrent readers have completed.

Root Cause

The root cause is a missing SRCU synchronization primitive in the error-handling branch of nvme_alloc_ns(). The RCU-safe list removal correctly deferred visibility of the deletion, but the absence of synchronize_srcu() before kfree(ns) allowed the object to be reclaimed while readers still referenced it. This is a classic race condition and use-after-free pattern.

Attack Vector

Triggering the flaw requires concurrent NVMe multipath activity during a namespace allocation failure. An attacker with the ability to induce namespace allocation errors while multipath I/O is in progress could race the free against an in-flight reader. Exploitation depends on winning a narrow timing window in kernel code paths, and practical impact ranges from kernel memory corruption and system instability to potential privilege escalation depending on the reclaimed slab contents.

No verified proof-of-concept code is publicly available. Technical details are documented in the upstream commits referenced below.

Detection Methods for CVE-2026-89972

Indicators of Compromise

Kernel oops or panic messages referencing nvme_find_path, nvme_mpath_revalidate_paths, or NVMe namespace list traversal
KASAN (Kernel Address Sanitizer) reports flagging use-after-free in the NVMe subsystem during namespace initialization failures
Unexpected NVMe controller resets or multipath failover events correlated with nvme_alloc_ns() failures in dmesg

Detection Strategies

Enable KASAN on test kernels to surface use-after-free access patterns in the NVMe driver
Monitor kernel logs for stack traces containing nvme_alloc_ns, out_unlink_ns, or list_del_rcu alongside NVMe multipath functions
Compare running kernel commit hashes against the fix commits 76023560d60f, d663944dbad8, and ef248d5de446 to identify unpatched hosts

Monitoring Recommendations

Ingest /var/log/kern.log and journalctl -k output into a centralized log platform and alert on NVMe error patterns
Track kernel version inventory across storage-heavy hosts and flag systems running unpatched builds
Correlate NVMe subsystem errors with host stability metrics such as unexpected reboots or storage I/O stalls

How to Mitigate CVE-2026-89972

Immediate Actions Required

Identify Linux hosts running NVMe multipath configurations and inventory their kernel versions
Apply the upstream stable kernel patches referenced in the fix commits as soon as vendor builds are available
Prioritize patching on servers exposing NVMe over Fabrics (NVMe-oF) targets, where remote namespace operations are more frequent

Patch Information

The fix adds a synchronize_srcu(&ns->head->srcu) call in the nvme_alloc_ns() error path after list_del_rcu(&ns->siblings) and before kfree(ns), mirroring the correct pattern already present in nvme_ns_remove(). The patch is available in the following upstream stable commits:

Consult your Linux distribution vendor for backported package builds.

Workarounds

No official workaround is documented; applying the upstream patch is the recommended remediation
Where patching is delayed, reduce exposure by avoiding configurations that repeatedly trigger nvme_alloc_ns() failures under active multipath I/O
Restrict local privileged access on affected hosts to limit who can induce namespace allocation error conditions