Linux kernel nvmet: metadata SGL allocation failure frees the data SGL against an unassigned p2p device

CVSS 7.5CVE-2026-98964Kernel, userspace & hypervisorcurated

Impact

On an NVMe-over-Fabrics target using PCI peer-to-peer memory, req->p2p_dev is only assigned after both the data and metadata SGL allocations succeed. If the data allocation succeeds and the metadata allocation then fails, the out_free_sg path hands the still-unset req->p2p_dev to pci_p2pmem_free_sgl(), so cleanup runs against the wrong (or NULL) PCI device instead of the one the data allocation came from. The exposure is narrow and reliability-shaped rather than directly steerable: it needs a target configured with P2P memory, a metadata-bearing (protection-information) command, and an allocation failure, which in practice means p2p pool pressure. The consequence on a storage node that exports NVMe-oF to a GPU fleet is a crash or a leaked/mismatched p2p allocation in the I/O path, which is a node-level outage for every client mounting that namespace. Hosts that are only NVMe-oF initiators, or targets with P2P DMA disabled, do not run this code.

Who can reach it

A remote initiator that can submit commands to the NVMe-oF target over the storage fabric, to the extent it can drive the target's p2p pool into allocation failure with metadata-bearing commands. Requires an established fabric connection; on most fleets that means the storage VLAN, not a tenant pod. Target-side configuration (P2P memory enabled) is a precondition.

What to do

Take the stable kernel that passes the local p2p_dev to the cleanup path (five stable branches fixed) and reboot the target nodes - nvmet is in the storage serving path, so this is a drain-and-reboot per target, not a live patch. Operators who cannot schedule that window can disable P2P memory on the nvmet port configuration to take the affected path out of use, at a throughput cost. The record names only the stable commits, no distro version.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-98964 https://git.kernel.org/stable/c/32f21607911a1f69c8f0f93a6c28fe6f8490aa98 https://git.kernel.org/stable/c/ce79a6c5cc1b8054ec8d3eba16adda4a36113438

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.