Linux kernel nvme: missing SRCU grace period on the namespace-allocation error path

CVSS 9.8CVE-2026-89972Kernel, userspace & hypervisorcurated

Impact

The error path in nvme_alloc_ns() removed the namespace from the head siblings list with list_del_rcu() and then freed it without waiting for SRCU readers. Multipath code walks that list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can dereference a freed namespace. Reaching it requires a namespace allocation to fail while multipath I/O is in flight, which in practice means a misbehaving or hot-plugged NVMe device rather than anything a tenant drives. On GPU nodes with local NVMe scratch the realistic outcome is a host crash during device probe, not a tenant-controlled escalation.

Who can reach it

Local and hardware-dependent. There is no network or tenant-reachable trigger described in the record; it needs a failing namespace setup concurrent with multipath path lookup.

What to do

Pick up a kernel with the added synchronize_srcu() on the error path and reboot at the next scheduled maintenance window. This does not warrant an emergency drain on its own; fold it into the regular kernel-update cycle. The record lists stable commits only.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-89972 https://git.kernel.org/stable/c/76023560d60f10b4f808941163aa2975f1631683 https://git.kernel.org/stable/c/d663944dbad81bb0e3635d7090db4713e6300858

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.