GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel NVMe: userspace num_keys drives a multi-megabyte kzalloc in nvme_pr_read_keys()

CVSS 7.1CVE-2026-23244Kernel, userspace & hypervisorcurated

Impact

The persistent-reservation read-keys ioctl takes num_keys from userspace, up to PR_KEYS_MAX, and passes the resulting size to kzalloc, so a caller can request roughly a 4 MB physically contiguous allocation and trip the page allocator's MAX_PAGE_ORDER warning. Impact is a kernel warning and a failed high-order allocation, not memory corruption; the fix is simply kvzalloc. It matters on GPU nodes only where a tenant workload holds an NVMe block device directly - local scratch passed into a pod, or a shared-storage host where PR ioctls are reachable - and even there the practical result is log noise and allocator pressure rather than a tenant boundary break. The CVSS metrics NVD carries for this record are considerably more severe than the described behaviour.

Who can reach it

Local user with an open file descriptor on an NVMe block device and permission to issue the persistent-reservation read-keys ioctl - typically root or a container granted the device. Not reachable remotely or from an unprivileged pod without device access.

What to do

Pick up the stable kernel patch (kzalloc -> kvzalloc in drivers/nvme/host/pr.c) in your distro kernel; applying it means a node reboot into the new kernel, so it fits a routine maintenance cycle rather than an emergency drain. Restricting direct NVMe device access for tenant pods removes the exposure without a reboot.

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.