Zum Inhalt springen
← Zurück zum Cyberlagebild
Zuletzt aktualisiert 23.10.2026 16:12

CVE-2026-98156

CVSS 7.81 Quelle

Beschreibung

Im Linux-Kernel wurde die folgende Sicherheitsanfälligkeit behoben: drm/virtio: Verwenden Sie die DMA-API für die Ressourcensicherung auf Xen Auf einer Xen-PV-Domainseite haben Adressen keine Beziehung zu den realen Maschinenadressen, die der Host verwenden müsste, um sie zu erreichen. virtio ring.c behandelt dies korrekt, vring use map api() gibt true für jede xen domain() unabhängig von VIRTIO F ACCESS PLATFORM zurück. virtio-gpu trifft die gleiche Entscheidung unabhängig, aber seine Kopie schaut nur auf das Feature-Bit: bool use dma api = !virtio has dma quirk(vgdev->vdev); QEMU setzt iommu platform standardmäßig nicht auf virtio-vga, also ist VIRTIO F ACCESS PLATFORM nicht ausgehandelt, use dma api ist false und virtio gpu object shmem init() beschreibt die Backing-Seiten des Framebuffers zum Host mit sg phys(). Das sind gastphysische Adressen. In einer PV-Domäne lösen sie sich auf der Host-Seite auf Seiten auf, die zu einer anderen Domäne gehören, so dass der Host nicht verwandten Speicher scannt. Bewegen Sie die Entscheidung in virtio gpu use dma api() und geben Sie ihr den xen domain()-Check, wie vring use map api(). Dies ermöglicht zusätzlich die Aufrufe dma sync sgtable for device() in virtgpu vq.c, die für die Richtigkeit erforderlich sind, wenn swiotlb im Spiel ist. Reproduziert mit einem Xen 4.21 PV dom0, das in QEMU 8.2 mit virtio-vga verschachtelt ist, sowohl auf einem Distro 6.8 Kernel als auch auf 6.18 LTS. Ein PVH dom0 funktioniert gut und benötigt diese Korrektur nicht, da es identitätsmapped ist, nur PV dom0s sind betroffen.

Herstellerlinux
Produktlinux kernel
ProduktfamilieKeine Angaben
Betroffene Versionen>=4.20 <6.18.53, >=6.19 <7.2.7, 7.3
Behobene VersionenKeine Angaben

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Herstellerhinweise prüfen und das betroffene Produkt kurzfristig patchen oder kompensierende Schutzmaßnahmen aktivieren.

PrioritätGelb
EinordnungZeitnah behandeln: hohes technisches Risiko.

Empfohlene Schritte

  • Betroffene Systeme identifizieren: linux linux kernel.
  • Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
  • Hersteller-Advisory öffnen und verfügbare Updates, Workarounds oder Deaktivierungen prüfen.
  • Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

  • Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
  • WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
  • Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
  • Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.