Linux kernel iommufd: hwpt replace responds to faults on the wrong domain, stranding faults on the old hwpt

Impact

iommufd_hwpt_replace_device() calls iommufd_auto_response_faults() with the *new* hwpt but the attach handle of the device's *old* domain. Fault groups are queued against the hwpt that was attached when the fault was delivered, so the scan looks in the wrong fault queue and outstanding I/O page-fault groups on the old domain are never auto-responded. The commit message identifies this as a refactor regression: the original fault.c code passed the old domain. In practice the device is left waiting on a page-fault response that will not come, with fault state leaked, on precisely the path a VMM or device-assignment agent uses when moving an assigned device between I/O page tables. That path is live on GPU nodes doing VFIO/iommufd passthrough of accelerators and SR-IOV NICs, and a device stuck in that state usually means draining the node rather than recovering it in place.

Who can reach it

Local and privileged: something must hold /dev/iommu and perform a hwpt replace on a fault-capable device - normally the hypervisor or device-assignment control plane, not an ordinary tenant workload. Not remotely reachable, and not reachable at all on hosts that do not use iommufd fault handling.

What to do

Update to a stable kernel carrying commits 564ac339, 8eb07702, adb87155 or ba5c0f28 and reboot each affected host; iommufd is built in, so there is no module-reload shortcut. The record names no fixed release number. Until then, avoiding hwpt replace on fault-capable domains avoids the affected path.

References

Related entries

• Microsoft Hyper-V: vmswitch fails to validate guest OID requestsCVE-2021-28476 · Microsoft Hyper-VCritical
• Incus: instance snapshots bypass restricted.containers.lowlevel, giving command execution on the hostCVE-2026-48751 · Incus (instance snapshots ignore restricted.containers.lowlevel)Critical
• VMware ESXi (OpenSLP): Use-after-free in OpenSLP on port 427 - unauthenticated remote code execution on the hypervisorCVE-2020-3992 · VMware ESXi (OpenSLP)Critical
• Linux kernel mlx5_core kTLS RX offload: TLS RX resync list corruption: entries are moved by the resync handlerCVE-2021-47215 · Linux kernel mlx5_core kTLS RX offloadCritical
• Linux kernel (drivers/nvme/host): The NVMe/RDMA initiator destroys the queue pair before the connection manager ID, soCVE-2021-47378 · Linux kernel (drivers/nvme/host)Critical
• Linux kernel (net/tls): KTLS stored a negative errno into the socket error field where a positive value is expected. ACVE-2021-47496 · Linux kernel (net/tls)Critical