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

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