UBUNTU-CVE-2026-97988: High severity ubuntu/linux-azure vulnerability
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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
After clearing ACCESS_PLATFORM, configure the vring addresses for the new address mode.
vhost-net and vhost-vsock userspace vring addresses = configure for the new address mode