GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux iommufd: vDEVICE alloc error path leaks the igroup mutex and deadlocks later vDEVICE operations

CVE-2026-80687Kernel, userspace & hypervisorcurated

Impact

iommufd_vdevice_alloc_ioctl() takes idev->igroup->lock, then validates the driver-supplied vdevice_size against the core structure size behind a WARN_ON_ONCE. On failure it jumped past the unlock label, leaving the igroup mutex held permanently - every subsequent vDEVICE operation on that IOMMU group blocks forever. iommufd is the path GPU and NIC passthrough runs through, so a stuck igroup means VMs or containers bound to those devices can no longer be set up or torn down and the node has to be rebooted to clear it. The failing branch is a driver/core size mismatch rather than anything a tenant supplies, so this is a bad-combination bug, not a tenant-reachable one - it needs a vIOMMU driver whose vdevice_size disagrees with the core kernel it is built against.

Who can reach it

Local, from a process holding /dev/iommu that issues the vDEVICE alloc ioctl - in practice the VMM or a passthrough-capable orchestrator, not a tenant workload. Reaching the buggy path additionally requires a vIOMMU driver reporting a mismatched vdevice_size, which the kernel already flags with WARN_ON_ONCE.

What to do

Fixed in the mainline Linux kernel by jumping to the unlock label; take the distro kernel update and reboot the host. A node that has already hit the leak cannot be recovered without a reboot, since the mutex is held by no live path. The record names no fixed release version, only the stable commits.

References

Related entries

All Kernel, userspace & hypervisor entries

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.