Sicherheitslücke im Kernel

Wir beginnen nun wie angekündigt mit der Wartung. Zunächst werden wir eine Canary node auserwählen und dann den patch mit dem Rest der Flotte parallel durchfahren. Als erstes Updaten wir den Standort Skylink EGH01.

Wir beginnen nun auch parallel das NTT FRA1 Cluster zu patchen.

Alle Systeme aus dem Skylink sind vollständig upgedated und alle KVM-Server laufen wieder wie gewohnt.

Alle RYZEN-9 Knoten sind geupdated.

Wartung abgeschlossen: Sicherheitsupdate aller Virtualisierungs-Hosts (Linux-Kernel, „PwnEscape“)

Kurzfassung: In der Nacht vom 15. auf den 16.10.2026 haben wir auf allen Virtualisierungs-Hosts an unseren Standorten Frankfurt und Eygelshoven ein kritisches Sicherheitsupdate des Linux-Kernels eingespielt. Dafür musste jeder Host einmal neu gestartet werden. Jede VM war nur während des Neustarts ihres Hosts nicht erreichbar, in der Regel 5 bis 15 Minuten. Alle VMs, die vor der Wartung liefen, laufen wieder. Daten sind dabei nicht verloren gegangen.

Worum ging es? Sicherheitsforscher haben eine Lücke im Netzwerk-Stack des Linux-Kernels veröffentlicht, bekannt als „PwnEscape“. Eine virtuelle Maschine konnte über manipulierte Prüfsummen-Informationen ihrer virtio-Netzwerkkarte den Kernel des Host-Systems dazu bringen, bereits ausgewertete Paket-Header zu überschreiben. In der Laborumgebung der Forscher ließ sich damit Speicher des Hosts auslesen und letztlich aus der VM heraus auf den Host durchgreifen. Betroffen sind KVM-basierte Virtualisierungsplattformen allgemein. Der Fehler steckte seit vielen Jahren im Linux-Kernel.

Die Korrektur wurde am 14.10.2026 in den offiziellen Linux-Kernel aufgenommen. Proxmox liefert sie mit dem Kernel 7.0.14-24 aus, den wir vor dem Einsatz geprüft haben. Ein Austausch des Kernels im laufenden Betrieb ist hier nicht möglich, daher waren Neustarts der Hosts erforderlich.

Was haben wir gemacht?

Den korrigierten Kernel auf allen Virtualisierungs-Hosts installiert und als festen Standard gesetzt. Zuerst einen einzelnen Host als Testlauf aktualisiert und beobachtet, danach die übrigen Hosts in Wellen. Interne Dienste vorab ohne Unterbrechung auf bereits aktualisierte Hosts verschoben. Die Hosts unseres verteilten Speichersystems (Ceph) einzeln nacheinander neu gestartet. Der Speicher blieb dadurch die ganze Zeit verfügbar und vollständig redundant. Nach jedem Neustart automatisch geprüft, dass der neue Kernel läuft und alle zuvor laufenden VMs wieder gestartet sind.

Zeitlicher Ablauf (MESZ)

Zeitraum, Bereich, Downtime je VM (ca.) 15.10., 23:15–23:30 Eygelshoven, Testlauf auf einem Host 10–15 min 15.10., 23:40 – 16.10., 00:30 Eygelshoven, alle übrigen Hosts in drei Wellen 10–15 min 16.10., 00:15–01:20 Frankfurt, Compute-Hosts in mehreren Wellen 5–15 min 16.10., 01:15– 02:45 Frankfurt, Speicher-Hosts nacheinander 10–20 min 16.10., 02:45 Wartung abgeschlossen

Was müssen Sie tun?

In der Regel nichts. Ihre VM läuft wieder. VMs, die vor der Wartung ausgeschaltet waren, haben wir bewusst nicht gestartet. Sollte Ihre VM nicht erreichbar sein, starten Sie sie bitte einmal über das Kundenpanel neu oder wenden Sie sich an unseren Support. Betreiben Sie in Ihrer VM selbst virtuelle Maschinen (z. B. KVM oder Proxmox), aktualisieren Sie bitte auch dort den Kernel, sobald Ihre Distribution den Fix ausliefert.

Wir danken Ihnen für Ihr Verständnis.