Linux kernel vhost: stale vring metadata cache lets a reconfigured vring access memory outside its IOTLB mapping

Impact

vhost caches the IOTLB mapping backing each vring metadata region and treats a cache hit as proof the region was already validated. VHOST_SET_VRING_ADDR and VHOST_SET_VRING_NUM can be issued while the vq is live and neither resets that cache nor validates the new GIOVAs at ioctl time, so the vhost worker keeps translating descriptor, avail and used ring addresses through the old mapping and hands the result to __copy_to_user()/__copy_from_user() without a bounds check. The result is host-kernel reads and writes outside the region the device IOTLB actually maps, driven by the userspace process that owns the vhost device. On a GPU node running accelerated VMs, that is a path for a compromised or hostile VMM process to reach host memory beyond its own guest's confinement; the vhost worker runs in the host kernel, so the blast radius is the hypervisor, not one tenant VM.

Who can reach it

Local process holding an open vhost device (/dev/vhost-net, /dev/vhost-vsock or similar) with a device IOTLB attached - in practice the VMM process such as QEMU. No remote or unauthenticated path; the attacker must already have the vhost fd, which normally means code execution in the VMM.

What to do

Take the stable-kernel fix that resets vq->meta_iotlb[] on vring reconfiguration (backported across the branches listed in the record) and reboot each hypervisor host, draining VMs and GPU workloads first; there is no runtime toggle and no upstream mitigation short of not exposing vhost devices with device IOTLB to untrusted VMM processes. The record names no fixed release numbers, only the stable commits, so check your distro's kernel advisory for the version that carries them.

References