CVE-2026-97988
Zusammenfassung
von VulDB • 25.09.2026
Im Linux-Kernel wurde die folgende Schwachstelle behoben:
vhost: Ungültigmachen des vring-Zugriffs bei IOTLB-Übergängen
Wenn sich VIRTIO_F_ACCESS_PLATFORM ändert, werden zwischengespeicherte vring-Zeiger und IOTLD-Metadaten in einem anderen Adressraum interpretiert. Das Beibehalten dieser Werte während des Übergangs kann dazu führen, dass veraltete Ringzuordnungen (stale ring mappings) weiterhin verwendet werden.
Das Löschen von d->iotlb vor dem Sichern der VQ-Sperren ermöglicht es einem Worker, ein transientes NULL für d->iotlb zu beobachten und beim Übersetzen eines Deskriptors auf d->umem zurückzugreifen.
Einfügen einer gemeinsamen vhost_clear_device_iotlb()-Hilfsfunktion für vhost-net und vhost-vsock. Sichern aller VQ-Mutexes in Indexreihenfolge vor dem Freigeben der geräteweiten IOTLB, Ungültigmachen des zwischengespeicherten Ringzugriffs und der Metadaten jedes VQ, Löschen ausstehender IOTLD-Nachrichten und Freigeben der alten Tabelle nach dem Übergang. Dies serialisiert den Übergang mit Workern und verhindert gemischte Adressraumzuordnungen.
Bei der ersten direkten IOTLB-Übergangsoperation werden die zwischengespeicherten vring-Adressen ungültig gemacht. Wenn eine bestehende Geräte-IOTLD ersetzt wird, bleiben die GIOVA-Ringadressen erhalten, und nur der Metadaten-Zwischenspeicher wird zurückgesetzt. Nach dem Löschen von ACCESS_PLATFORM muss der Benutzeranwendungsteil (Userspace) die vring-Adressen für den neuen Adressmodus konfigurieren.
vhost_vq_invalidate_access() macht desc, avail und used gemeinsam ungültig. Der VQ gilt nur dann als ungültig gemacht, wenn alle drei NULL sind, da eine einzelne GIOVA-Adresse rechtmäßig null sein kann.
If you want to get best quality of vulnerability data, you may have to visit VulDB.