CVE-2026-97988: vhost: invalidate vring access on IOTLB transitions
In the Linux kernel, the following vulnerability has been resolved:
vhost: invalidate vring access on IOTLB transitions
When VIRTIOFACCESSPLATFORM changes, cached vring pointers and IOTLB metadata are interpreted in a different address space. Keeping them across the transition can leave stale ring mappings in use.
Clearing d->iotlb before taking the VQ locks also lets a worker observe a transient NULL d->iotlb and fall back to d->umem while translating a descriptor.
Add a common vhostcleardeviceiotlb() helper for vhost-net and vhost-vsock. Take all VQ mutexes in index order before dropping the device-wide IOTLB, invalidate each VQ's cached ring access and metadata, clear pending IOTLB messages, and free the old table after the handoff. This serializes the transition with workers and prevents mixed address space mappings.
On the first direct-to-IOTLB transition, invalidate the cached vring addresses. When an existing device IOTLB is replaced, preserve the GIOVA ring addresses and reset only the metadata cache. After clearing ACCESSPLATFORM, userspace must configure the vring addresses for the new address mode.
vhostvqinvalidateaccess() clears desc, avail, and used together. Treat the VQ as invalidated only when all three are NULL, since a single GIOVA address may legitimately be zero.
Affected Software
Event History
Frequently Asked Questions
Which vhost configurations are affected?
The issue concerns vhost-net and vhost-vsock devices when VIRTIO_F_ACCESS_PLATFORM changes, causing vring pointers and IOTLB metadata to be interpreted in a different address space. Affected transitions include direct-to-IOTLB operation, replacement of an existing device IOTLB, and clearing ACCESS_PLATFORM.
What must occur for the stale mapping condition to arise?
VIRTIO_F_ACCESS_PLATFORM must transition while cached vring access or IOTLB metadata remains available. A concurrent worker can also observe a transient NULL device IOTLB during the transition and use the userspace memory mapping instead when translating a descriptor.
What operational action is required after ACCESS_PLATFORM is cleared?
Userspace must configure the vring addresses again for the new address mode. Cached vring addresses cannot safely be retained across that transition.
How does the fix prevent mixed address-space mappings?
It takes all virtqueue mutexes in index order before replacing or dropping the device IOTLB, invalidates cached ring access and metadata, clears pending IOTLB messages, and frees the old table only after handoff. For a first direct-to-IOTLB transition it invalidates cached vring addresses; when replacing an existing IOTLB it preserves GIOVA ring addresses but resets metadata caches.