Die IPv6-Fragmentierungsschwachstelle, die die Container-Isolation in EL10 untergräbt

Die Kurzfassung

Was: Eine Schwachstelle in Linux, die eine lokale Rechteausweitung und das Entkommen aus Containern ermöglicht und den Spitznamen „ipv6-frag-escape“ trägt. Ein Rechenfehler im Ausgabepfad für IPv6-Pakete (__ip6_append_data()) wählt für den linearen Kopf eines Socket-Puffers eine zu kleine Größe von fraggap Bytes, sodass eine spätere Kopie in den skb_shared_info am Ende derselben Zuweisung. Dieser Heap-Überlauf innerhalb des Slabs reicht aus, um einen Prozess ohne Sonderrechte innerhalb eines Containers auf dem Host zu einem Root-Prozess zu machen. Zum Zeitpunkt der Veröffentlichung wurde noch keine CVE-Nummer vergeben.

Auswirkung: Ein öffentlicher Proof-of-Concept von sgkdev (github.com/sgkdev/ipv6_frag_escape) ermöglicht den Zugriff auf eine interaktive Root-Shell in den ursprünglichen Namespaces und im Root-Dateisystem des Hosts, ausgehend von einem Prozess ohne Sonderrechte innerhalb eines netzwerkisolierten Containers. Die README-Datei listet getestete Ziele auf, darunter CentOS Stream 10 auf 6.12.0-242.el10 und RHEL 10 auf 6.12.0-228.el10. KernelCare hat „Host-Root“ am 29. Juni 2026 intern auf AlmaLinux 10.2 (6.12.0-211.7.3.el10_2) reproduziert – uid=0 in den Init-Namespaces, bereits beim ersten Versuch.

Status: Dies ist ein Fehler in der Hauptzweig-Version, der im Upstream in Linux 7.2-rc1 durch einen Merge-Commit behoben wurde. 38becddc, das den IPv6-Fix enthält 736b380e28d0 und das IPv4-Pendant eca856950f7c. Betroffen sind die Versionen 6.6 bis 7.1. Bis heute Vormittag gab es noch keine Backports für die Distribution; das ändert sich jedoch bereits – AlmaLinux hat die Upstream-IPv4/IPv6-Patches integriert fraggap Korrekturen im Quellcode des Kernel-Pakets am 30. Juni um 08:51 UTC (6.12.0-211.28.2). Überprüfen Sie die Repos Ihrer Distribution, bevor Sie davon ausgehen, dass Sie noch auf eine Korrektur warten müssen.

Schweregrad: Hoch für betroffene EL10-Systeme. Lokaler Angriffsvektor, geringe Komplexität, sobald die Voraussetzungen gegeben sind, keine Benutzerinteraktion und ein funktionierender öffentlicher Exploit gegen die Standardversion von EL10. Es liegt kein CVSS-Wert vor, da noch keine CVE-Nummer vergeben wurde. Fehlerklasse: Linearer Heap-/Slab-Überlauf → „Use-after-free“-Angriff auf Seiten → Rechteausweitung und Namespace-Escape.

Warum das wichtig ist: Der Trigger ist für jeden Prozess ohne Sonderrechte erreichbar – das geht aus dem Upstream-Fix-Commit direkt hervor: Ein UDPv6-Socket, der MSG_MORE zusammen mit MSG_SPLICE_PAGES. Es sind keine Host-Rechte erforderlich, sondern lediglich Zugriff auf nicht privilegierte Benutzernamensräume innerhalb des Containers. Container-Hosts, Shared Hosting, CI-Runner und Multi-Tenant-Linux-Umgebungen sind genau die Umgebungen, in denen dies scheitert, da der Exploit auf der falschen Seite der Grenze endet, um die herum diese Plattformen aufgebaut sind.

Mach das jetzt: Wende einen festen Kernel oder einen KernelCare Patch ohne Neustart, sofern verfügbar. Bis dahin ist die wirksamste Übergangslösung für EL10 das Booten mit init_on_alloc=1, wodurch der öffentlich bekannte Exploit nur noch zu einem Kernel-Absturz statt zu einer Root-Shell führt – dies ist unter Ubuntu und Debian bereits die Standardeinstellung bei der Kompilierung, weshalb derselbe Fehler dort nur zu einem DoS-Angriff führt. Sofern Ihre Arbeitslast dies zulässt, können Sie durch das Deaktivieren nicht privilegierter Benutzernamensräume die Escape-Primitive beseitigen. Betrachten Sie beides als Übergangslösungen.

Die Langfassung

„ipv6-frag-escape“ ist ein weiteres Beispiel dafür, wie sich ein Fehler im Linux-Kernel von einer „kleinen arithmetischen Korrektur“ zu einem „öffentlich bekannten Root-Exploit“ entwickelt, noch bevor die meisten Organisationen über eine CVE-Kennung, eine Scanner-Regel oder einen Herstellerhinweis verfügen, auf deren Grundlage sie Maßnahmen ergreifen können.

KernelCare wurde am 29. Juni auf den öffentlich zugänglichen PoC aufmerksam und konnte den Host-Root-Zugriff am folgenden Morgen intern auf einem AlmaLinux 10.2-System in Standardkonfiguration reproduzieren; kurz darauf wurde ein Patch ohne Neustart in den Build integriert.

Das Repo beschreibt sich selbst als zuverlässige Methode zum Ausbruch aus nicht privilegierten Containern und Jails unter CentOS und RHEL 10, die sich einen inzwischen behobenen IPv6-Fragmentierungsfehler in __ip6_append_data() was zu einem linearen Überlauf innerhalb der Platte in skb_shared_info.

Bevor wir zu den Details kommen, sollte man sich eines vor Augen halten: Es handelt sich um einen Fehler in der Hauptzweig-Version, nicht um eine Eigenart von EL10. Jeder Kernel von 6.6 bis 7.1, der noch nicht gepatcht wurde, enthält den anfälligen Code. EL10 ist lediglich die einzige Zielplattform, für die es derzeit einen öffentlich zugänglichen, ausnutzbaren Exploit gibt, und die Schwachstellen in diesem Exploit betreffen EL10 uname „check“, 5-stufige Paginierung, „init-on-alloc“ deaktiviert – das sind Eigenschaften der Waffe, nicht des Fehlers.

So funktioniert der Exploit

Die Kette reicht von einem Schreibvorgang in einen nicht privilegierten Socket bis hin zu einer Root-Shell auf dem Host:

[Unprivileged socket input]
│  UDPv6 + MSG_MORE + MSG_SPLICE_PAGES
▼
[__ip6_append_data() miscalculation]
│  linear head under-sized by fraggap bytes
▼
[Linear slab overflow]
│  writes past skb->end into skb_shared_info
▼
[Page use-after-free]
│  put_page() drops a ref on an attacker-owned page
▼
[Dirty-Pagetable reclamation]
│  freed page reused as a leaf page table → kernel R/W
▼
[Host namespace escape]
│  credentials overwritten, SELinux neutered, core_pattern hijacked
▼
[Host root shell (uid=0)]

Der Zuweisungsfehler. In net/ipv6/ip6_output.c, wenn __ip6_append_data() wählt den Zweig für die seitenweise Zuweisung, den es berechnet alloclen = fragheaderlen + transhdrlen und pagedlen = datalen - transhdrlen. Das Problem ist, dass datalen enthält bereits fraggap – Bytes, die aus dem vorherigen SKB übernommen und anschließend in den linearen Kopf kopiert werden. Der Kopf ist also um genau fraggap Bytes, während pagedlen wird um denselben Betrag überbewertet.

Der Überlauf. Die nachfolgende Kopie überschreibt den bisherigen Inhalt skb->end in die skb_shared_info am Ende des eigenen Head-Objekts des Pakets. Ein klarer, innerhalb des Slabs liegender linearer Heap-Überlauf.

Der Auslöser. Ein Prozess ohne Sonderrechte gelangt über einen UDPv6-Socket auf den fehlerhaften Pfad, indem er MSG_MORE zusammen mit MSG_SPLICE_PAGES. Die fehlerhafte Abrechnung wurde bereits in Version 6.0 durch den Zero-Copy-Sendepfad eingeführt, blieb jedoch bis zur MSG_SPLICE_PAGES In 6.6 wurde der Pfad fortgesetzt, anstatt zurückzukehren. -EINVAL. Deshalb ist 6,6 die Untergrenze.

Überlauf bei Lese-/Schreibvorgängen im Kernel. Durch die Korruption erhält man die Kontrolle über den Einzelnen nr_frags Byte in skb_shared_info. Mit einem Pipe-Buffer-Seitenzeiger, der zuvor in einem nicht initialisierten frags[] Slot, Sockel-Demontage (skb_release_data() → put_page()) setzt einen Verweis auf eine Seite, die sich noch im Besitz des Angreifers befindet, wodurch der Überlauf zu einem „Use-after-free“-Fehler auf Seitenebene wird. Die freigegebene Seite wird dann als Page-Table der untersten Ebene wiederverwendet – der sogenannte „Dirty-Page-Table“-Zustand –, sodass eine einzelne physische Seite sowohl eine aktive Page-Table als auch eine Seite ist, auf die der Angreifer weiterhin über die Pipe liest und schreibt. Ein gefälschtes, selbst-aliasingendes PTE erweitert dies zu umfassenden Lese- und Schreibzugriffen auf den Kernel.

Flucht zum Gastgeber. Ausgehend von Lese-/Schreibzugriffen auf den Kernel umgeht der PoC KASLR mithilfe der festen SMP-Trampolin-Seitentabelle im unteren Speicherbereich, überschreibt Prozess-Anmeldedaten, patcht den SELinux-Denial-Path im Speicher und kapert core_pattern Ein „usermodehelper“ läuft also als Root in den ursprünglichen Namespaces des Hosts. Dieser letzte Schritt ist der Ausweg.

Die öffentliche README-Datei dokumentiert diese Kette, lässt jedoch bewusst die Zuverlässigkeitsmaßnahmen außer Acht – die PCP-Grooming- und Cross-Cache-Verfahren, die für einen konsistenten Ablauf sorgen – und beschränkt die ausgelieferte Binärdatei auf EL10 mit einer 5-Level-Paging-Anforderung. Es handelt sich um einen Proof-of-Concept, nicht um eine einsatzbereite Waffe. Für Verteidiger sind jedoch zwei Konsequenzen von Bedeutung: Nachdem der Exploit ausgeführt wurde, getenforce berichtet weiterhin Enforcing Auch wenn die SELinux-Durchsetzung abgeschwächt wurde und die Beschädigung im Kernel-Speicher statt auf der Festplatte vorliegt, sodass Tools zur Dateiintegritätsprüfung nichts zu melden haben.

Was sich durch den Upstream-Fix ändert

Die Korrektur umfasst nur wenige Zeilen, und genau deshalb wird das Problem leicht unterschätzt. Auf dem Pfad der paginierten IPv6-Zuweisung wird Folgendes hinzugefügt: fraggap zu alloclen und zieht es von pagedlen, sodass der lineare Kopfspeicher groß genug für die tatsächlich darin kopierten Bytes ist und sich der paginierte Teil entsprechend verkleinert. Außerdem wird der nun überflüssige MSG_SPLICE_PAGES Ausnahme bei der Prüfung auf negative Kopien.

Der IPv4-Pfad in __ip_append_data() wies denselben Buchhaltungsfehler auf und wird auf dieselbe Weise korrigiert (eca856950f7c). IPv6 stellt den ausnutzbaren, schwerwiegenderen Fall dar; das IPv4-Pendant wurde der Vollständigkeit halber ebenfalls behoben. Da beide Funktionen die Sendewege paketweise verarbeiten und keinen persistenten Zustand führen, ist die Korrektur ein heißer Kandidat für einen nahezu wortgetreuen Patch, der keinen Neustart erfordert.

Wer ist betroffen?

Die Sicherheitslücke ist umfassender als der Exploit. Die sicherste Arbeitshypothese lautet, dass jeder Kernel im Bereich von 6.6 bis 7.1 diesen Fehler enthält, sofern er nicht über den Upstream-Fix oder einen Downstream-Backport verfügt. Der öffentlich zugängliche PoC ist hingegen absichtlich eng gefasst: Er zielt auf Kernel der EL10-Familie der Version 6.12.x ab, benötigt nicht privilegierte Benutzernamensräume, setzt 5-stufiges Paging (LA57) voraus und hängt von CONFIG_INIT_ON_ALLOC_DEFAULT_ON ausgeschaltet sein.

Ausnutzbarkeit bestätigt – Root-Zugang auf dem Host festgestellt:

• CentOS Stream 10 auf 6.12.0-242.el10, vom PoC-Autor als Ziel angegeben.
• RHEL 10 auf 6.12.0-228.el10, ebenfalls vom PoC-Autor aufgeführt.
• AlmaLinux 10.2 auf 6.12.0-211.7.3.el10_2, intern von KernelCare am 29. Juni 2026 reproduziert.

Voraussichtlich betroffene Personen: RHEL 10, CentOS Stream 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10 und CloudLinux OS 10, auf denen betroffene Kernel der EL10-Familie der Version 6.12.x ohne den Fix oder einen Patch ohne Neustart laufen. Diese Distributionen basieren auf denselben Build-Voraussetzungen wie RHEL 10, darunter init_on_alloc ausgeschaltet, behandeln Sie sie daher als ungeschützt, sofern Sie nichts anderes festgestellt haben.

Fehler vorhanden, derzeitige öffentliche Technik beschränkt sich auf einen Denial-of-Service-Angriff:

• Ubuntu 24.04 „Noble“ (6.8) und Debian 13 „Trixie“ (6.12.x). Die Tests von KernelCare ergaben CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y auf die ausgelieferten Kernel, wodurch der eingefügte „stale“-Zeiger auf Null gesetzt wird und die Kette zu einem Kernel-Absturz statt zu einem Root-Escape führt. Der PoC ist zudem fest auf EL10 beschränkt. uname sowie auf 5-Level-Paging, sodass es auf diesen Systemen im Auslieferungszustand nicht läuft.

Dieses ausschließlich auf DoS ausgerichtete Ergebnis ist spezifisch für die derzeitige Technik. Die README-Datei weist darauf hin, dass ein anderer Exploit, der „init-on-alloc“ berücksichtigt, folgen könnte, sobald der Fix und eine CVE veröffentlicht sind. Behandeln Sie Ubuntu und Debian als anfällig, aber derzeit nicht ausnutzbar – nicht als sicher.

Von diesem Auslöser nicht betroffen:

• Kernel-Versionen älter als 6.6, bei denen die MSG_SPLICE_PAGES Der Pfad fehlt und der Trigger gibt einen Wert zurück -EINVAL.
• Kernel mit Merge-Funktion 38becddc, IPv6-Korrektur 736b380e28d0, IPv4-Korrektur eca856950f7coder ein nachgelagertes Backport.

Ein Hinweis: Ein System, das die Annahmen des PoC einfach nicht erfüllt – beispielsweise 4-Level-Paging –, wird dadurch nicht behoben. Es ist zwar vor genau diesem PoC geschützt, doch der Kernel-Fehler bleibt im Hintergrund weiterhin bestehen.

Jetzt Maßnahmen ergreifen

Die dauerhafte Lösung ist ein gepatchter Kernel oder ein „KernelCare“- Patch, der keinen Neustart erfordert. Bis diese Lösung flächendeckend verfügbar ist, gibt es zwei praktische Möglichkeiten.

1. Aktivieren Sie „init-on-alloc“ (empfohlen unter EL10). Der öffentlich bekannte Exploit basiert darauf, einen ungültigen Zeiger im nicht initialisierten Slab-Speicher zu platzieren. Das Zurücksetzen des Speichers auf Null bei der Zuweisung unterbindet diesen Angriff. Unter Ubuntu und Debian ist diese Option standardmäßig bereits aktiviert; unter EL10 ist sie in der Regel deaktiviert.

Überprüfen Sie die Kernel-Konfiguration, nicht die Boot-Befehlszeile – dies ist in der Regel eine Standard-Einstellung aus der Kompilierungsphase und wird nicht in /proc/cmdline:

grep CONFIG_INIT_ON_ALLOC_DEFAULT_ON /boot/config-$(uname -r)   # =y means on

So schalten Sie das Gerät ein, wenn es ausgeschaltet ist:

sudo grubby --update-kernel=ALL --args="init_on_alloc=1"
sudo reboot

Der Aufwand beschränkt sich auf einen geringen Overhead des Allokators. Der Haken daran ist, dass ein Neustart erforderlich ist, damit die Änderung wirksam wird; daher eignet sich diese Lösung eher für ein Wartungsfenster als für eine Notfallreaktion innerhalb derselben Minute.

2. Deaktivieren Sie die Namespaces für Benutzer ohne Sonderrechte. Die Kette beginnt bei einem Prozess ohne Sonderrechte innerhalb eines Containers und stützt sich auf das Verhalten von Namespaces ohne Sonderrechte. Durch das Entfernen dieser Primitive wird der öffentliche Pfad unabhängig vom Status des Allokators unterbrochen.

sysctl user.max_user_namespaces             # check current value
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-ipv6-frag-escape.conf

Dies führt zu Fehlfunktionen bei rootless Podman und Docker, bei einigen CI-Sandboxen, bei Sandboxen im Flatpak-Stil, bei unshare(1) ohne Sonderrechte sowie bei Browser-Sandboxen. Auf dedizierten Serverprofilen funktioniert alles einwandfrei, auf Entwickler- und Container-Hosts kommt es jedoch zu Störungen. Vor einer flächendeckenden Einführung sollte ein Test durchgeführt werden.

Entscheidungsmoment: Wenn auf dem Host keine rootless-Container laufen und ein Neustart möglich ist → set init_on_alloc=1; dadurch wird der Fehler als Absturz eingestuft, selbst wenn die „userns“-Primitive später wieder zurückkehrt. Wenn ein Neustart nicht möglich ist, Sie aber auf nicht privilegierte „userns“ verzichten können, deaktivieren Sie diese Funktion als vorübergehende Notlösung ohne Neustart. Wenn Sie sowohl rootless Container als auch null Ausfallzeit benötigen, ist der Patch für den Neustart ohne Neustart oder ein korrigierter Kernel die einzige wirkliche Lösung, und Sie sollten nicht vertrauenswürdige lokale Ausführungen isolieren, bis eine dieser Lösungen verfügbar ist.

KernelCare Rebootless Patch

Beides __ip6_append_data() und __ip_append_data() Es handelt sich um Sendepfade pro Paket ohne persistenten Cross-Call-Zustand, wodurch die arithmetische Korrektur auf der Upstream-Seite eine saubere Portierung von kpatch darstellt.

Feed-Status (30.06.2026, 09:00 UTC): EL10-Builds werden nun nach und nach in den Test-Feed für RHEL 10, Oracle Linux 10, Rocky Linux 10 und AlmaLinux 10 aufgenommen.

Nach der Validierung aus dem Test-Feed übernehmen:

sudo kcarectl --update --prefix test

Sobald der Beitrag in den Hauptfeed aufgenommen wurde, erscheint er beim nächsten planmäßigen Durchlauf – oder Sie können ihn auf Abruf abrufen:

sudo kcarectl --update

Überprüfen Sie, ob der Patch aktiv ist:

kcarectl --info | grep kpatch-build-time      # build dated 2026-06-30 or later

Sobald eine CVE zugewiesen wurde, kcarectl --patch-info | grep CVE-2026- sollte dies ebenfalls bekannt werden. Unabhängig davon: Falls Sie EL10-Kernel direkt verwalten, enthält AlmaLinux bereits seit dem 30. Juni die Upstream-Korrekturen in seinem Kernel-Paket-Quellcode (6.12.0-211.28.2) – es lohnt sich, Ihre Repos und die Repos anderer Anbieter im Auge zu behalten, um die entsprechenden Errata zu finden.

Erkennung

Für diese Art von Sicherheitslücke gibt es keine eindeutigen Anzeichen nach der Ausnutzung. Die Kette endet mit beliebigen Lese- und Schreibzugriffen im Kernel und kann die SELinux-Durchsetzung deaktivieren, während normale Statusprüfungen weiterhin unauffällig erscheinen und sich auf der Festplatte nichts ändert. Die Anzeichen, die tatsächlich auf das Verhalten dieses Exploits hindeuten, sind verhaltensbezogen:

• Unerwartete Änderungen an /proc/sys/kernel/core_pattern, insbesondere ein |-Handler mit dem Präfix „-“ – der PoC überschreibt diesen, um einen Usermodehelper als Root zu starten.
• Ein Container oder ein untergeordneter Prozess stürzt ab, unmittelbar bevor ein ungewöhnlicher privilegierter Prozess auf dem Host gestartet wird.
• Lücken bei der SELinux-Überwachung: Die Durchsetzung scheint aktiviert zu sein, doch auf einem Host, der eigentlich entsprechende Ablehnungen generieren sollte, werden diese nicht mehr angezeigt.

Prüfung core_pattern und achten Sie auf die Abfolge „Absturz – anschließende Ausführung mit erhöhten Rechten“. Betrachten Sie diese eher als schwache Anzeichen denn als Beweis. Beachten Sie, dass dieser PoC KASLR über die feste SMP-Trampolin-Seitentabelle umgeht, sodass er nicht lesen muss /proc/kallsyms oder BTF – diese klassischen Anzeichen für Kernel-Exploits treten hier nicht auf. Sollte ein nicht vertrauenswürdiger oder nur bedingt vertrauenswürdiger Benutzer oder eine entsprechende Arbeitslast während des Sicherheitsfensters lokale Ausführungsrechte auf einem betroffenen EL10-Host gehabt haben, sollten Sie der Installation des Patches Priorität einräumen und davon ausgehen, dass der Host möglicherweise einer eingehenderen Überprüfung bedarf.

Warum gerade dieses Thema wichtig ist

„ipv6-frag-escape“ ist keine Remote-Code-Ausführung und auch kein Fehler, der „jeden Linux-Rechner sofort lahmlegt“. Für Container-Hosts, Shared-Hosting-Plattformen, CI-Systeme, Entwickler-Sandboxes und Multi-Tenant-Linux-Umgebungen ist die Auswirkung in gewisser Hinsicht sogar noch gravierender: Sie untergräbt genau jene Grenze, auf der diese Plattformen aufbauen. Der Exploit beginnt mit einem Prozess ohne Sonderrechte und endet mit Root-Rechten in den ursprünglichen Namespaces des Hosts.

Wenn bereits vor der Veröffentlichung einer CVE oder eines stabilen Backports ein funktionierender PoC vorliegt, gibt es für den üblichen, durch Scanner gesteuerten Patch-Workflow keinen Auslöser. Die Sicherheitsverantwortlichen müssen direkt auf der Grundlage der technischen Fakten handeln. Die Korrektur ist geringfügig. Die operative Dringlichkeit hingegen ist groß.

Checkliste für priorisierte Sanierungsmaßnahmen

1. Wenden Sie den Patch oder den Neustart-freien Patch zunächst auf betroffene EL10-Systeme an, insbesondere auf Container-Hosts und überall dort, wo nicht vertrauenswürdiger oder teilweise vertrauenswürdiger Code ausgeführt werden kann.
2. Aktivieren init_on_alloc=1 sofern noch kein fester Kernel oder ein Patch ohne Neustart bereitgestellt wurde.
3. Deaktivieren Sie nicht privilegierte Benutzernamensräume, sofern die Arbeitslast dies zulässt.
4. Behandeln Sie Ubuntu 24.04 und Debian 13 als „mit Fehlern behaftet, aktuelle öffentliche Technik blockiert“ und nicht als sicher.
5. Prüfung core_pattern sowie SELinux-Zugriffsverweigerungen auf exponierten Hosts.
6. Behalten Sie die Zuordnung von CVEs und nachfolgende Errata der Hersteller im Auge und überprüfen Sie die Systeme erneut, sobald stabile Backports verfügbar sind – auch wenn der öffentliche PoC in Ihrer Umgebung nie ausgeführt wurde.

Referenzen

• Öffentlicher PoC: https://github.com/sgkdev/ipv6_frag_escape
• Korrektur für die Zusammenführung im Upstream (7.2-rc1): https://github.com/torvalds/linux/commit/38becddc332c1dbee6ab8dc8f13a860c6280b905
• IPv6-Korrektur 736b380e28d0; IPv4-Korrektur eca856950f7c; Trigger aktivieren ce650a166335; Fehler verursachend 773ba4fe9104 (IPv6) / 8eb77cc73977 (IPv4)
• Backport des AlmaLinux-Kernel-Pakets (6.12.0-211.28.2): AlmaLinux-Betriebssystem-Git-Server, Commit 674503c679

Patches für jeden Kernel – ganz ohne Neustart. Wenn Sie KernelCare noch nicht nutzen, ist jetzt der richtige Zeitpunkt, um zu erfahren, wie Patches ohne Neustart kritische Linux-Systeme schützen – ganz ohne Notfall-Wartungsfenster oder Ausfallzeiten.

Holen Sie sich KernelCare noch heute →