Linux kernel (drivers/iommu/iommufd): A tenant using nested translation can ask iommufd to process a cache-invalidation

CVSS 6.5CVE-2026-64289Kernel, userspace & hypervisorcurated

Impact

A tenant using nested translation can ask iommufd to process a cache-invalidation batch of essentially unbounded size, pinning a CPU in a non-preemptible loop until the soft-lockup watchdog fires. On a node booted with softlockup_panic that is a panic; otherwise it is a burnt core plus a wedged IOMMU invalidation path that every other tenant on the box shares.

Who can reach it

One IOMMUFD_CMD_HWPT_INVALIDATE ioctl from a tenant container holding /dev/iommu, with entry_num or entry_len set near U32_MAX. No host root and no special hardware beyond a nested/vIOMMU setup (VT-d nested is the case called out in the fix). Trivially repeatable, so a tenant can burn cores one at a time.

What to do

Update to a stable kernel carrying commits d2bd041e / 32ca4aed. Interim: do not expose /dev/iommu to untrusted tenants directly - run passthrough through an operator-controlled VMM - and do not boot tenant nodes with softlockup_panic, which converts this from a stalled core into a full node panic.

References

https://git.kernel.org/stable/c/d2bd041e0efaf7d81789779b135279d18b33d6d5 https://git.kernel.org/stable/c/32ca4aed2a66205b072fcfecabe220289a8149ff https://nvd.nist.gov/vuln/detail/CVE-2026-64289

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.