Linux kernel (drivers/iommu/iommufd): Iommufd accepted any non-zero virtual event queue depth up to U32_MAX, so a

Impact

Iommufd accepted any non-zero virtual event queue depth up to U32_MAX, so a tenant can ask the kernel to allocate an arbitrarily large queue and drive the node into memory exhaustion. That is an OOM kill storm or a hung box for every tenant on the host, from one ioctl.

Who can reach it

A single IOMMUFD_CMD_VEVENTQ_ALLOC from a container holding /dev/iommu, with veventq_depth set enormous. No host root, no hardware prerequisite beyond a vIOMMU/nested setup that exposes virtual event queues.

What to do

Update to a stable kernel carrying commits f565297e / e7b5e556, which caps the depth. Interim: keep /dev/iommu out of tenant containers and set per-container memory cgroup limits that the kernel allocation is charged against where your kernel supports it.

References

Related entries

• Linux kernel (drivers/iommu/iommufd): A failed copy_to_user while draining the iommufd fault queue restarts the sameCVE-2026-64290 · Linux kernel (drivers/iommu/iommufd)Medium
• Linux kernel (drivers/iommu/iommufd): A user-supplied page shift of 63 overflows the divisor in the iommufdCVE-2025-40293 · Linux kernel (drivers/iommu/iommufd)Medium
• Linux kernel (drivers/iommu/iommufd): The vfio type1 info structure is not zeroed before being filled and copied outCVE-2023-54034 · Linux kernel (drivers/iommu/iommufd)Medium
• Linux kernel (drivers/iommu/iommufd): The iommufd dirty-tracking bitmap computed an index by shifting a 32-bit constantCVE-2025-21724 · Linux kernel (drivers/iommu/iommufd)Medium
• Linux kernel (drivers/iommu/iommufd): Splitting a mapping area - which is what a partial unmap does - leaves theCVE-2023-52801 · Linux kernel (drivers/iommu/iommufd)High
• Linux kernel (drivers/iommu/iommufd): An unmap runs off the end of the pinned page list and drops pin counts on pagesCVE-2023-53630 · Linux kernel (drivers/iommu/iommufd)High