Xen XSA-526 bis XSA-528: Gäste können Host über Linux-Backends abstürzen lassen

Das Xen-Sicherheitsteam hat am 6. November 2026 drei Advisories zu den Linux-Backend-Treibern veröffentlicht: XSA-526 (CVE-2026-100080) und XSA-527 (CVE-2026-100081) betreffen xen-netback, XSA-528 (CVE-2026-100082) betrifft xen-blkback. Noch am selben Tag erschienen die stabilen Kernel 7.3.3, 6.18.62, 6.12.116, 6.6.162, 6.1.192, 5.15.225 und 5.10.274, die nur diese drei Korrekturen enthalten.

Betroffen sind Xen-Hosts, deren Dom0 oder Treiberdomäne einen Linux-Kernel mit den eingebauten Netz- und Block-Backends nutzt. Ein Gast kann damit im schlimmsten Fall den ganzen Host abstürzen lassen. Die Fehler stecken in Xen-spezifischen Treibern, die andere Hypervisoren wie KVM, VMware oder Hyper-V nicht nutzen. Weil XSA-526 und eng verwandte Fehler zu XSA-527 und XSA-528 laut Xen-Team bereits öffentlich waren, gehört das Kernel-Update auf Xen-Hosts mit fremden oder wenig vertrauenswürdigen Gästen ins nächste kurzfristige Wartungsfenster.

Was ist passiert?

Alle drei Fehler sind Use-after-free-Lücken beim Abbau virtueller Geräte. Bei XSA-526 gibt xen-netback die per RCU geschützten Statistikdaten frei, ohne den RCU-Zustand abzuwarten, wenn der Aufbau der Verbindung zum Gast scheitert, etwa wegen ungültiger Xenstore-Daten aus dem Gast. Liest in diesem Moment jemand die Statistik über sysfs, greift der Kernel auf bereits freigegebenen Speicher zu. XSA-527 betrifft die Multicast-Behandlung: Die Suche in der Multicast-Liste kann parallel zum Abbau eines Geräts laufen und dabei freigegebene Daten lesen. XSA-528 beschreibt dasselbe Muster bei den I/O-Statistiken in xen-blkback.

Die Korrekturen stammen von Jürgen Groß und Jan Beulich, wie die Ankündigung zu Linux 7.3.3 zeigt. Für zwei weitere Advisories, XSA-529 und XSA-530, nennt die Xen-Übersicht den 10. November als Veröffentlichungstermin, Inhalte sind noch unter Embargo.

Wer ist betroffen?

Laut den Advisories sind verwundbar: xen-netback ab Linux 4.11 (XSA-526) und ab Linux 4.3 (XSA-527), xen-blkback ab Linux 4.5 (XSA-528). Entscheidend ist der Kernel der Domäne, die die Backends bereitstellt, also meist Dom0. Verwundbar sind die Backend-Treiber, nicht der Frontend-Teil in den Gästen.

Entschärft wird das Problem laut den Advisories, wenn die Backends im Userspace laufen, etwa mit den QEMU-Backends „qnic“ für Netz und „qdisk“ für Block, oder wenn jeder Gast eine eigene Treiberdomäne hat. Ob Xen-basierte Produkte und Distributionen die Fixes bereits in eigene Pakete übernommen haben, geht aus den Advisories nicht hervor.

Wie kritisch ist das?

Ausgelöst werden die Fehler aus einem Gast heraus, bei XSA-526 etwa durch manipulierte Xenstore-Daten. Das wahrscheinlichste Ergebnis ist laut Xen-Team ein Absturz des Treibers, der sich zum Absturz des Hosts ausweiten kann. Das ist ein Denial of Service für alle VMs auf dem Host. Informationslecks schließen alle drei Advisories nicht aus. Nur bei XSA-527 nennt das Xen-Team zusätzlich eine Rechteausweitung, allerdings ausdrücklich als sehr unwahrscheinlich. Bei XSA-526 und XSA-528 muss zusätzlich die Statistik gerade in der Abbauphase gelesen werden, bei XSA-526 über sysfs. CVSS-Werte nennen die Advisories nicht.

Für einen einzelnen Host mit eigenen, vertrauenswürdigen VMs ist das Risiko gering. Bei Hostern, Laborumgebungen und Mandantensystemen, in denen Dritte Root in ihren Gästen haben, ist ein Host-Absturz durch einen Gast dagegen ein reales Betriebsrisiko.

Was sollten Admins jetzt tun?

• Inventar: alle Xen-Hosts und Treiberdomänen erfassen und mit uname -r die laufende Kernel-Version notieren.
• Prüfen, ob netback und blkback als Kernel-Backends laufen oder ob QEMU-Backends im Userspace genutzt werden.
• Patchstand: auf 7.3.3, 6.18.62, 6.12.116, 6.6.162, 6.1.192, 5.15.225 oder 5.10.274 aktualisieren oder auf das Distributionspaket mit den Fixes warten und dieses einspielen.
• Hosts mit fremden oder wenig vertrauenswürdigen Gästen zuerst patchen, für den Neustart VMs vorher migrieren.
• Bis zum Update ungewöhnliche Abstürze und Kernel-Meldungen zu xen-netback oder xen-blkback im Host-Log beobachten.
• Den 10. November für XSA-529 und XSA-530 vormerken, falls dafür ein weiteres Update samt Neustart nötig wird. Inhalt und betroffene Komponenten sind noch unbekannt.

Einordnung für Unternehmen

Nach XSA-523 vom 3. November ist das die zweite Runde von Xen-Fixes innerhalb einer Woche, die nächste ist schon angekündigt. Betreiber von Xen-Umgebungen können nach Einschätzung der Redaktion prüfen, ob sich Updates bis zum 10. November bündeln lassen, ohne Mandantensysteme zu lange offen zu lassen. Ob die angekündigten Advisories überhaupt einen Neustart erfordern, ist offen. Die beschriebenen Fehler führen in erster Linie zu Ausfällen, nicht zu Datenabfluss. Wer viele VMs auf wenigen Hosts betreibt, sollte gerade deshalb die Verfügbarkeit im Blick haben.

Passende Anleitungen auf S-EDV

• Xen-Lücke XSA-523: Bösartige VM liest und schreibt Speicher von Host und Gästen
• Automatische Sicherheitsupdates unter Debian/Ubuntu mit unattended-upgrades richtig konfigurieren

Quellen

• Xen Project: Advisory XSA-526 zu CVE-2026-100080
• Xen Project: Advisory XSA-527 zu CVE-2026-100081
• Xen Project: Advisory XSA-528 zu CVE-2026-100082
• Xen Project: Übersicht der Sicherheitsadvisories
• LWN: Ankündigung von Linux 7.3.3
• LWN: Meldung zu sieben stabilen Kerneln mit den Xen-Fixes