Description
In the Linux kernel, the following vulnerability has been resolved:

vhost: invalidate vring access on IOTLB transitions

When VIRTIO_F_ACCESS_PLATFORM 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 vhost_clear_device_iotlb() 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
ACCESS_PLATFORM, userspace must configure the vring addresses for the
new address mode.

vhost_vq_invalidate_access() 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.
Published: 2026-09-25
Score: n/a
EPSS: n/a
KEV: No
Impact: Kernel memory corruption from stale vring pointers
Action: Patch Kernel
AI Analysis

Impact

The flaw resides in the Linux kernel’s vhost subsystem and occurs when the VIRTIO_F_ACCESS_PLATFORM feature toggles or the IOTLB is refreshed. Cached vring pointers and IOTLB metadata, which are interpreted in a different address space after a transition, are left untouched, allowing stale ring mappings to remain active. An attacker could exploit this by inducing a transition while a worker or descriptor translation is in progress, potentially causing the kernel to read or write to an incorrect memory location, leading to kernel memory corruption, data loss, or denial of service.

Affected Systems

This issue affects the Linux kernel via the vhost‑net and vhost‑vsock modules. No specific kernel versions are listed in the data; any running kernel using vhost with the VIRTIO_F_ACCESS_PLATFORM capability is potentially vulnerable until the patch is applied.

Risk and Exploitability

The CVSS score is not provided in the source data, and no EPSS value is available, so the measured severity is indeterminate. The likely attack vector is a local or privileged process that can trigger a vhost IOTLB transition, such as a userspace application using the vhost interface. Because the vulnerability manifests through stale internal state rather than an externally exploitable input, the risk is moderate to high for systems that use vhost with address space transition support. The vulnerability is not listed in the KEV catalog, but because it can lead to kernel memory corruption, it warrants timely remediation.

Generated by OpenCVE AI on September 25, 2026 at 14:25 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a release that incorporates the vhost IOTLB transition fix described in the source commits.
  • If the patch cannot be applied immediately, configure vhost devices to disable the VIRTIO_F_ACCESS_PLATFORM feature so that address space transitions are not triggered.
  • Apply the specific patch from the kernel source tree or backport it to the running kernel if a newer kernel is not available, following the guidelines in the provided commit references.

Generated by OpenCVE AI on September 25, 2026 at 14:25 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 25 Sep 2026 14:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Fri, 25 Sep 2026 10:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: vhost: invalidate vring access on IOTLB transitions When VIRTIO_F_ACCESS_PLATFORM 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 vhost_clear_device_iotlb() 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 ACCESS_PLATFORM, userspace must configure the vring addresses for the new address mode. vhost_vq_invalidate_access() 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.
Title vhost: invalidate vring access on IOTLB transitions
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-25T10:23:21.998Z

Reserved: 2026-09-25T10:18:58.209Z

Link: CVE-2026-97988

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-25T11:17:26.903

Modified: 2026-09-25T11:17:26.903

Link: CVE-2026-97988

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-25T14:30:14Z

Weaknesses