GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel NVMe: bio leaked when integrity mapping fails on a user-mapped request

CVE-2026-64072Kernel, userspace & hypervisorcurated

Impact

The local bio variable in the NVMe user-request mapping path is always NULL, so when the integrity (protection-information) mapping fails the bio is never released and the allocation leaks. Each failed request leaks again, so a caller that can repeat the failing operation slowly consumes kernel memory on the node until the box degrades or the OOM killer starts taking jobs. Exposure is narrow and privileged: it needs access to the NVMe character device for passthrough I/O and a namespace configured with metadata/PI, which on a normal GPU node means root on the host rather than a tenant in a pod. Treat this as a host reliability and long-uptime concern for storage nodes and for any host that hands /dev/nvme* into a privileged container, not as a tenant escape.

Who can reach it

Local user holding an NVMe character device (/dev/nvmeX) able to submit passthrough I/O against a metadata/PI-enabled namespace - normally root on the host, or a privileged container that was given the device. Not reachable from an ordinary GPU pod.

What to do

Pick up the stable kernel update containing the fix and reboot each affected node on the normal rolling schedule; a leak of this shape does not justify an emergency window. Until the reboot, the leak only accrues if something is actually driving failing integrity-mapped passthrough I/O, so check whether any agent on the node does NVMe passthrough before prioritising, and watch slab growth on long-uptime storage hosts.

References

Related entries

All Kernel, userspace & hypervisor entries

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.