GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel iommufd: NULL dereference racing IOAS change_process against a file-backed mapping

UnscoredCVE-2026-80817Kernel, userspace & hypervisorcurated

Impact

iommufd_ioas_change_process() walks every IOAS area holding only iova_rwsem and assumes each area has a non-NULL pages pointer. iopt_map_pages() works in two phases: it inserts the area into the interval tree under iova_rwsem with area->pages still NULL, then drops that lock and fills pages under domains_rwsem. In that window a concurrent change_process ioctl observes the half-built area and oopses on the NULL pages pointer, as the included syzkaller trace from iommufd_fops_ioctl shows. iommufd is the modern path for device passthrough, so this is reachable from whoever holds an iommufd file descriptor - the VMM handling GPU or NIC assignment. The outcome in the record is a kernel oops, i.e. a crash of the host that is running assigned-device guests; nothing in the description establishes exploitability beyond that.

Who can reach it

Local process holding an iommufd file descriptor - typically the VMM or device-assignment agent on a passthrough host - issuing IOAS change_process concurrently with a file-backed page mapping. Requires whatever privilege your setup needs to open /dev/iommu; no remote path.

What to do

Apply the stable kernel fix on hosts using iommufd for device passthrough. Kernel change, so drain the guests and reboot each host onto the patched kernel unless you livepatch. There is no configuration toggle short of not using the change_process ioctl, which is not under your control if the VMM issues it.

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.