Linux kernel (drivers/nvme/host): The PRP list mempool is sized in the wrong units, so a large I/O that needs two PRP

Impact

The PRP list mempool is sized in the wrong units, so a large I/O that needs two PRP lists writes past the end of the pool allocation. This is a genuine heap overflow on the local NVMe data path - kfence caught it in practice - so one tenant's I/O can corrupt kernel memory belonging to the rest of the node.

Who can reach it

Reachable by any unprivileged process on the node that can issue I/O to a local PCIe NVMe device (a container with a scratch volume is enough) - no /dev/nvme passthrough required. The window is narrow: it needs roughly a 4MB transfer split into 127 physical segments on a submission queue whose controller does not support SGLs. Most enterprise NVMe negotiates SGLs and is therefore not on this path, so check controller capability before rating this urgent on a given SKU.

What to do

No fixed version is listed on this record - boot a kernel carrying the linked stable commits. Interim: confirm whether the node's NVMe controllers advertise SGL support (SGL-capable queues do not take this path), and cap the maximum I/O size handed to tenants on any controller that does not.

References