CVE-2026-74580: vhost: reset the vring metadata cache on vring reconfiguration
In the Linux kernel, the following vulnerability has been resolved:
vhost: reset the vring metadata cache on vring reconfiguration
vq->metaiotlb[] caches the vhostiotlbmap that backs each vring metadata region, and iotlbaccessok() returns early on a cache hit, taking the hit as proof that the region has already been validated:
if (vhostvqmetafetch(vq, addr, len, type)) return true;
The cache is reset on VHOSTIOTLBUPDATE and VHOSTIOTLBINVALIDATE, on device IOTLB (re)initialisation and on vq reset, but not when VHOSTSETVRINGADDR replaces vq->desc, vq->avail and vq->used, nor when VHOSTSETVRINGNUM changes the region sizes.
With a device IOTLB attached both ioctls are accepted while the vq is live, and neither validates the addresses at ioctl time: vqaccessok() and vqlogusedaccessok() return true early because the addresses are GIOVAs, deferring validation to prefetch time. Once the cache has been populated that deferred validation no longer runs -- vqmetaprefetch() hits the stale entry and returns true -- and vhostvqmetafetch() keeps translating through the old mapping as
map->addr + addr - map->start
for an address the mapping no longer covers. vhostcopytouser() and vhostcopyfromuser() consume the result with copytouser() and copyfromuser(), which do not check it either, so a subsequent used ring update or descriptor fetch accesses memory outside the region the IOTLB actually maps.
Reset the metadata cache whenever the vring is reconfigured, so the new addresses are pushed back through iotlbaccessok()'s slow path.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Reset the vq metadata cache whenever the vring is reconfigured: reset it on VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE, and when VHOST_SET_VRING_ADDR replaces vq->desc/vq->avail/vq->used, so stale IOTLB metadata entries are not used for deferred validation.
Linux kernel vhost (vhost_iotlb) Reset vq metadata cache on vring reconfiguration = implemented via VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE, and on VHOST_SET_VRING_ADDR vring replacement (not on VHOST_SET_VRING_NUM region size changes)
Event History
Frequently Asked Questions
Which vhost configurations are exposed to this issue?
The issue requires a device IOTLB to be attached to the vhost device. It is relevant when a live virtqueue is reconfigured through VHOST_SET_VRING_ADDR or VHOST_SET_VRING_NUM after metadata mappings have been cached.
What must happen for stale metadata validation to be used?
The metadata cache must first be populated for the existing vring mapping. If the vring addresses or sizes are then changed while the queue remains live, validation can be skipped on a cache hit and translation can continue through the old mapping.
What can be done before applying the resolved change?
Avoid changing vring addresses or sizes on a live queue with a device IOTLB attached. Resetting the virtqueue, or updating or invalidating the IOTLB mapping before reconfiguration, clears the metadata cache according to the described behavior.