Wie KernelCare Januscape gepatcht hat, bevor OVHcloud mit seinen Massen-Neustarts begann

Wichtigste Erkenntnisse:

• OVHcloud hat Januscape durch einen Neustart von Zehntausenden von Hosts über einen Zeitraum von 11 Tagen behoben, was mit tatsächlichen Ausfallzeiten, Hardwareausfällen und der Einrichtung einer globalen Krisenstab einherging.
• KernelCare stellte beide erforderlichen Januscape-Korrekturen als Patches ohne Neustart, auch als „Live-Patches“ bekannt, bereit, wobei die Abdeckung im Main-Feed bereits am 7. Juli begann – noch vor der ersten Neustartwelle von OVH am 8. Juli.
• Bei Patches, die einen Neustart erfordern, bleibt jeder Host bis zum Zeitpunkt seines Neustarts angreifbar, während bei Patches ohne Neustart das Sicherheitsrisiko sofort nach der Installation des Patches beseitigt wird.

OVHcloud hat eine der offensten Nachbetrachtungen zur Infrastruktur veröffentlicht, die die Hosting-Branche seit Jahren gesehen hat.

Um die als CVE-2026-53359 erfasste Sicherheitslücke „Januscape“ zu beheben, hat das Unternehmen Zehntausende von KVM-Hosts, auf denen rund eine Million virtuelle Maschinen laufen, mit einem Patch versehen und neu gestartet. Der Einsatz erstreckte sich über alle Kontinente, erforderte eine Krisenreaktion rund um die Uhr und dauerte insgesamt 11 Tage.

„The Register“ berichtete über die Kampagne. Die vollständige Nachbetrachtung von OVHcloud ist für alle lesenswert, die für einen großen Virtualisierungsbestand verantwortlich sind.

Als Beispiel für die operative Arbeit ist dies wirklich beeindruckend. Die Teams von OVHcloud handelten zügig, bewältigten Störungen unter Druck und dokumentierten die Ergebnisse mit außergewöhnlicher Transparenz.

Als Thema im Bereich Infrastruktur wirft dies eine schwierigere Frage auf.

Warum war für die Anwendung eines einzigen Kernel-Patches ein globaler Neustart erforderlich?

Hier liegt der Unterschied: Für die von KernelCare unterstützten Plattformen war der Neustart-freie Januscape-Fix bereits im Haupt-Patch-Feed verfügbar, bevor OVH seinen ersten Host neu gestartet hat. Die abonnierten Flotten haben ihn im Rahmen eines normalen Update-Zyklus übernommen. Keine Neustarts. Keine Unterbrechungen. Keine Kampagne.

Januscape in zwei Sätzen

Januscape ist eine „Use-after-free“-Sicherheitslücke im x86-Shadow-Speicherverwaltungscode von KVM. Ein Angreifer mit Root-Zugriff innerhalb einer virtuellen Gastmaschine könnte diese Sicherheitslücke ausnutzen, um den Host zum Absturz zu bringen und möglicherweise Code mit Host-Rechten auszuführen.

Die Sicherheitslücke betrifft Intel- und AMD-Systeme und war rund 16 Jahre lang im Linux-Kernel vorhanden. Zu ihrer Behebung sind zwei miteinander verbundene Korrekturen im Upstream-Code erforderlich, die mit den CVE-Nummern CVE-2026-53359 und CVE-2026-46113 verbunden sind.

Unsere technische Januscape-Analyse behandelt die Schwachstelle, den Ausnutzungsweg und die erforderlichen Korrekturmaßnahmen im Detail.

Wir haben außerdem einen Live-Stream veranstaltet, in dem die Sicherheitslücke näher erläutert wird – falls Sie es vorziehen, zwei Experten über die CVE diskutieren zu hören, anstatt noch mehr darüber zu lesen.

Der Artikel, den Sie gerade lesen, befasst sich mit dem Haushaltsgesetz.

Was für Patches, die einen Neustart erfordern, notwendig ist

Alle folgenden Informationen stammen aus dem Postmortem von OVH und dem Artikel im „Register“. Es handelt sich dabei um keine Spekulationen.

OVHcloud testete sein Bereitstellungsverfahren zunächst in Sydney. Diese Region zeichnete sich durch einen relativ geringen Platzbedarf, eine geringere Nachfrage in den Nachtstunden und eine Abdeckung während der Geschäftszeiten durch Teams in Europa aus. Nachdem das Runbook validiert worden war, wurden die Neustarts im Rahmen eines „Follow-the-Sun“-Betriebs weltweit durchgeführt.

Dieser Vorgang umfasste weit mehr als nur die Installation eines Kernel-Pakets und den Neustart der Rechner. Die Neustartwellen wurden durch Stoppschwellenwerte geregelt. OVHcloud unterbrach eine Welle, wenn in einer Region mit hoher Dichte 15 Hosts gleichzeitig ausgefallen waren oder anderswo fünf Hosts ausgefallen waren.

Für Kundenprojekte, die auf mehrere Hosts verteilt waren, erstellten die Orchestratoren ein Co-Location-Diagramm. Ziel war es, zu verhindern, dass zwei Hosts, die dasselbe Projekt unterstützen, innerhalb desselben Zeitfensters neu gestartet werden.

Außerdem erfassten die Teams vor jeder regionalen Einführung die internen Serviceabhängigkeiten. Einige kritische virtuelle Maschinen mussten zunächst live migriert werden, damit Datenbanken, APIs, Überwachungssysteme und andere Betriebsdienste während der Neustarts weiterhin verfügbar blieben.

Kunden, deren Instanzen sich alle auf einem einzigen Host befanden, waren von einer Unterbrechung betroffen. Ihnen wurde zwar ein Zeitfenster angekündigt, doch aufgrund der Dringlichkeit der Sicherheitsmaßnahme war ein Verzicht darauf nicht praktikabel.

Dann kam die reale Welt ins Spiel. In der ersten Nacht kehrten etwa 20 bis 30 der insgesamt 6.000 Hosts nicht von selbst zurück: defekte Speichermodule, BIOS-Probleme, ausgefallene Netzwerkschnittstellen.

Bei einigen Rechnern in den USA mussten zunächst die CMOS-Batterie entfernt und der Akku entladen werden, bevor sie hochfuhren. Während dieser Zeit waren an jedem Standort Techniker des Rechenzentrums im Einsatz, die Bauteile austauschten und Arbeiten direkt an den Serverschränken durchführten, die kein Orchestrator automatisieren kann.

Auch die Software machte Probleme. Virtuelle Maschinen ließen sich nach einem Neustart des Hosts nicht mehr starten, bis ein Konflikt zwischen libvirt und den Gast-Systemen entdeckt und umgangen wurde. Durch erzwungene Abschaltungen wurden Daten auf virtuellen Maschinen in drei Clustern beschädigt. Die OpenStack-APIs in Paris gerieten in einen Deadlock, der zwei Stunden lang zu HTTP-503-Fehlern führte und eine Welle verzögerte. Am kanadischen Standort erreichte das Datenaufkommen das Zehnfache der normalen Spitzenlast und überforderte den Support.

Ehre, wem Ehre gebührt: Die Krisenzelle von OVH hat das gut gemeistert, und die Veröffentlichung der Ausfälle erfordert mehr Mut, als die meisten Anbieter aufbringen.

Das Problem lag nicht in der Ausführung. Das Problem ist das Patching-Modell, das diese erforderlich machte.

Was Systeme mit KernelCare-Schutz stattdessen taten

Flotten, die KernelCare einsetzten, bewältigten dieselbe Sicherheitslücke ohne die oben beschriebenen betrieblichen Maßnahmen. Keine Neustartwellen, keine Wartungsfenster, keine Einsatzplanung für Techniker.

Das aktuelle Ziel von TuxCare bei lokalen Privilegieneskalationen und Zero-Day-Schwachstellen ist es, innerhalb von 48 Stunden nach der öffentlichen Bekanntgabe Live-Patches bereitzustellen. In diesem Fall wurde diese Frist sogar unterschritten: Die Sperrfrist endete am 6. Juli, und KernelCare begann am 7. Juli (etwa 24 Stunden später) mit der Bereitstellung beider erforderlicher Korrekturen über seinen üblichen Patch-Prozess ohne Neustart, der manchmal auch als „Live-Patching“ bezeichnet wird.

Wie in unserer technischen Analyse zu Januscape dokumentiert, umfasste das allgemein verfügbare Angebot zum 7. Juli Folgendes:

• Die Enterprise Linux 10-Produktfamilie
• Ubuntu 22.04, einschließlich Cloud-Varianten
• Debian 13
• Ubuntu-Focal-Systeme, die den Jammy-Kernel zur Hardwareunterstützung verwenden
• Proxmox VE 7 und 8

Weitere Kernel-Familien durchliefen anschließend die Entwicklungs- und Testphase sowie eine schrittweise Einführung.

OVHcloud startete am folgenden Tag, dem 8. Juli, die ersten Neustartwellen in Sydney.

Während also ein Teil der Betreiber noch Ausfallzeiten plante, waren die mit Patches versehene Flotten bereits abgesichert – mit dem üblichen Vorbehalt, dass dies nicht beweist, dass die Patches vom 7. Juli auf die eigenen Debian-Kernel von OVHcloud in der Produktion anwendbar gewesen wären. OVHcloud hat nicht genügend Versionsinformationen veröffentlicht, um dies festzustellen.

Dies verdeutlicht die betriebliche Alternative, die Hosting-Anbietern mit unterstützten Kerneln zur Verfügung steht.

Sobald der entsprechende Patch, der keinen Neustart erforderte, auf dem System verfügbar war, konnte der anfällige Code ersetzt werden, ohne den Host neu zu starten. Es musste kein Zeitfenster für einen Neustart eingeplant werden, die Arbeitslasten der Kunden mussten nicht um einen Neustart herum koordiniert werden, und es war keine Benachrichtigung der Kunden bezüglich des Neustarts erforderlich.

Es gab auch keine schlummernden Hardwareprobleme, die bei einem Notneustart zum Vorschein hätten kommen können.

Administratoren könnten den Versicherungsschutz direkt überprüfen:

kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113'

Der Unterschied besteht nicht darin, dass die eine Gruppe Januscape ernst genommen hat und die andere nicht. Beide haben es getan.

Durch den Ansatz von OVH wurde die Fehlerbehebung zu einem bedeutenden Infrastrukturereignis, während ein Patch-Einsatz ohne Neustart mithilfe von KernelCare dies zu einer routinemäßigen Patch-Bereitstellung gemacht hätte.

Das Expositionsfenster ist der versteckte Kostenfaktor

Die Installation eines gepatchten Kernel-Pakets schützt den aktuell laufenden Kernel nicht. Die Sicherheitslücke bleibt bestehen, bis der Rechner mit der aktualisierten Version neu gestartet wird.

Dadurch entsteht ein Sicherheitsrisiko für jeden Host, der noch darauf wartet, an die Reihe zu kommen.

OVHcloud hat dieses Problem ausdrücklich anerkannt. Eine individuelle Betreuung der Kunden hätte die Kampagne verlängert und einen Großteil der Infrastruktur wochenlang ungeschützt gelassen. Das Unternehmen hat zudem die öffentliche Kommunikation während der Einführung eingeschränkt, da es befürchtete, dass Kunden den öffentlich zugänglichen Crash-Exploit an der Produktionsinfrastruktur testen könnten.

Bei der Patch-Installation ohne Neustart schließt sich das Fenster, sobald der betreffende Patch erfolgreich angewendet wurde. Eine herkömmliche Kernel-Aktualisierung und ein Neustart können dann später im Rahmen eines geplanten Wartungszyklus erfolgen und müssen nicht mitten in einer Sicherheitskrise durchgeführt werden.

Sind Patches ohne Neustart zu instabil?

OVHcloud hat die Möglichkeit eines unterbrechungsfreien Patching geprüft und verworfen. In der nachträglichen Analyse wird argumentiert, dass eine Änderung eines laufenden Kernels die Sicherheit beeinträchtigen und zu einer flottenweiten Instabilität führen kann.

Diese Frage verdient eine direkte Antwort. Betrachten wir das Ganze einmal aus drei Blickwinkeln:

Zunächst einmal dazu, wie diese Patches tatsächlich bereitgestellt werden. Jeder KernelCare-Patch wird für die jeweilige Kernel-Version, auf die er abzielt, erstellt und getestet; anschließend durchläuft er eine interne Validierung sowie stufenweise Tests, bevor er in den Produktions-Feed gelangt. Flotten, die eine weitere Prüfstufe wünschen, nutzen das KernelCare ePortal und richten ihre eigenen Genehmigungsstufen und Rollout-Richtlinien ein. Dies ist eine ausgereifte Bereitstellungspipeline.

Zweitens: dieser spezielle Fehler. Der Januscape-Fix ist ein Musterbeispiel für einen Kandidaten für ein Patch ohne Neustart: eine in sich geschlossene Korrektur im KVM-MMU-Fehlerpfad, ohne persistenten Zustand, der migriert werden müsste, und ohne Datenstrukturen, die transformiert werden müssten. Würde man eine CVE entwerfen, um zu veranschaulichen, wozu Patches ohne Neustart dienen, würde sie genau so aussehen wie diese.

Drittens – und das ist der Punkt, über den man sich Gedanken machen sollte: OVHs eigene Nachbetrachtung belegt die Instabilität des Neustartprozesses. Dutzende von Hosts, die nie wieder online gingen. Durch erzwungene Abschaltungen beschädigte Festplatten. Ein regionaler API-Deadlock. Durch einen Dienstkonflikt offline gestrandete VMs. Die Wahl stand nie zwischen einem riskanten Patch ohne Neustart und einem risikofreien Neustart. Es ging um zwei Methoden mit unterschiedlichen Risikoprofilen, und auf Flottenebene sind die Risiken des Neustart-Pfads groß, konkret und dokumentiert. Stabilität ist eine Eigenschaft des gesamten Behebungspfads, nicht des Patch-Mechanismus für sich genommen.

Wenn Ihre Infrastruktur innerhalb von 24 Stunden vollständig neu gestartet werden kann, ohne dass es zu Beeinträchtigungen für die Kunden kommt, sieht die Rechnung für Sie möglicherweise ganz anders aus. Wenn ein Kernel-CVE eine mehrwöchige Kampagne, einen Krisenstab und Techniker in jedem Rechenzentrum bedeutet, ist das Modell das Problem – nicht Ihr Team.

Kampagne mit Neustart versus Patching ohne Neustart

Das wird wahrscheinlich wieder passieren

Januscape war kein Einzelfall.

CopyFail, DirtyFrag, GhostLock und andere schwerwiegende Kernel-Sicherheitslücken haben die Infrastrukturteams dazu gezwungen, dringende Entscheidungen hinsichtlich des Risikos, der Ausfallzeiten und der Abhilfemaßnahmen zu treffen.

Der CISO von OVHcloud räumte ein, dass weitere Kernel-Sicherheitslücken eine Wiederholung des Notfallverfahrens erforderlich machen könnten. Die unmittelbare Aufgabe des Unternehmens besteht nun darin, dieses Verfahren für das nächste Mal sicherer und berechenbarer zu gestalten.

Andere Hosting-Anbieter bieten eine weitere Option an.

Sie können bereits von vornherein die Häufigkeit verringern, mit der eine Kernel-Sicherheitslücke zu einem Infrastrukturvorfall mit Auswirkungen auf die Kunden führt.

OVHcloud hat gezeigt, wie gut sich eine groß angelegte Neustart-Kampagne unter Zeitdruck durchführen lässt. KernelCare hat demonstriert, dass bei unterstützten Systemen dieselbe Sicherheitslücke aus einem laufenden Kernel beseitigt werden kann, ohne eine solche Kampagne einzuleiten.

Die bleibende Erkenntnis aus Januscape ist nicht, dass Hosting-Anbieter ein besseres Runbook für den Neustart benötigen.

Es geht darum, dass sie nicht jedes Mal, wenn eine kritische Kernel-Sicherheitslücke auftritt, eine solche aktivieren müssen.

Nutzen Sie Patches ohne Neustart mit KernelCare →