In the Linux kernel, the following vulnerability has been resolved:
nvme: add missing SRCU grace period in error path
nvme_alloc_ns() error path at out_unlink_ns removes ns from the
namespace head siblings list with list_del_rcu(&ns->siblings) but
does not wait for SRCU readers before freeing the namespace struct.
Multipath code iterates the head->list under srcu_read_lock() in
nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent
reader can still hold a reference to ns when kfree(ns) runs.
The normal removal path in nvme_ns_remove() correctly calls
synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for
in-progress readers. Add the same grace period in the error path.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - NVMe host core scans namespaces from NVMe-oF (nvme-tcp/rdma/fc) when a remote target sends NS_CHANGED AENs or Identify data; a malicious or compromised fabric target drives nvme_scan_ns→nvme_alloc_ns and the out_unlink_ns UAF over the network (typically TCP 4420).
AC:L - The remote target controls both sides of the race: it can stall then fail Identify after list_add_tail_rcu so the new path is on head->list, while concurrent multipath I/O or ANA AENs walk that list under srcu_read_lock in nvme_find_path/nvme_mpath_revalidate_paths; CONFIG_NVME_MULTIPATH is the recommended default.
PR:N - The attacker is the NVMe-oF peer and needs no host account or capability; NVMe/TCP is unauthenticated by default (TLS and DH-HMAC-CHAP are optional), and AENs plus Identify responses are accepted on an already-established fabrics session.
UI:N - NVMe-oF controllers are persistent boot/autoconnect configuration; namespace rescans, ANA updates, and multipath I/O run from kernel workqueues and the block layer with no further victim action at exploit time.
S:U - The use-after-free corrupts kernel heap (struct nvme_ns) inside the host NVMe driver and does not cross a VM, IOMMU, or other distinct security authority.
C:H - Use-after-free of the namespace object on the multipath siblings list lets an attacker reclaim the kmalloc slab and obtain a kernel read primitive from stale ns->disk/ctrl/flags dereferences in nvme_find_path.
I:H - The same UAF is heap-sprayable: multipath I/O and ioctl paths dereference fields of the freed nvme_ns, enabling arbitrary write and control-flow hijacking in kernel context.
A:H - Any use-after-free of ns during the SRCU list walk can oops or panic the host kernel even without a full exploit, taking down the NVMe storage stack.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - NVMe host core scans namespaces from NVMe-oF (nvme-tcp/rdma/fc) when a remote target sends NS_CHANGED AENs or Identify data; a malicious or compromised fabric target drives nvme_scan_ns→nvme_alloc_ns and the out_unlink_ns UAF over the network (typically TCP 4420).
AC:L - The remote target controls both sides of the race: it can stall then fail Identify after list_add_tail_rcu so the new path is on head->list, while concurrent multipath I/O or ANA AENs walk that list under srcu_read_lock in nvme_find_path/nvme_mpath_revalidate_paths; CONFIG_NVME_MULTIPATH is the recommended default.
PR:N - The attacker is the NVMe-oF peer and needs no host account or capability; NVMe/TCP is unauthenticated by default (TLS and DH-HMAC-CHAP are optional), and AENs plus Identify responses are accepted on an already-established fabrics session.
UI:N - NVMe-oF controllers are persistent boot/autoconnect configuration; namespace rescans, ANA updates, and multipath I/O run from kernel workqueues and the block layer with no further victim action at exploit time.
S:U - The use-after-free corrupts kernel heap (struct nvme_ns) inside the host NVMe driver and does not cross a VM, IOMMU, or other distinct security authority.
C:H - Use-after-free of the namespace object on the multipath siblings list lets an attacker reclaim the kmalloc slab and obtain a kernel read primitive from stale ns->disk/ctrl/flags dereferences in nvme_find_path.
I:H - The same UAF is heap-sprayable: multipath I/O and ioctl paths dereference fields of the freed nvme_ns, enabling arbitrary write and control-flow hijacking in kernel context.
A:H - Any use-after-free of ns during the SRCU list walk can oops or panic the host kernel even without a full exploit, taking down the NVMe storage stack.
CVSS 3.1