Database/Kernel, userspace & hypervisor
Linux kernel VFIO drivers/vfio/pci/vfio_pci.c - VFIO_DEVICE_SET_IRQS ioctl: A state-machine confusion in
Impact
A state-machine confusion in VFIO_DEVICE_SET_IRQS lets a caller sidestep the integer-overflow checks on the interrupt-configuration path and write kernel memory outside the intended area. The holder of the VFIO device file descriptor is the process that owns a tenant's passed-through GPU - the QEMU instance, or in a container-based GPU cloud the tenant's own runtime. This is therefore the direct escape route from 'we gave the tenant a GPU' to 'the tenant is writing host kernel memory', in the code path that every VFIO passthrough setup executes.
Who can reach it
Local process holding an open VFIO PCI device fd - i.e. the per-tenant VMM, or any workload granted /dev/vfio access for userspace device drivers or DPDK-style datapaths.
What to do
Kernel upgrade including commit 05692d7005a364add85c6e25a6c4447ce08f913a (which fixes this and CVE-2016-9084 together); RHEL shipped it in RHSA-2017:0386. Rolling reboot. Meaningful hardening independent of the patch: do not hand /dev/vfio/* into tenant containers. When passthrough is done through a VMM the fd stays in a process you control, and the exposure is bounded by that VMM's own hardening; handing the fd to tenant code removes that layer entirely.
References
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.