CVE-2026-98276 wurde im Upstream behoben. Daraufhin stürzte ein Server zwölf Mal ab.

Wichtigste Erkenntnisse

• CVE-2026-98276 ermöglicht es einem lokalen Benutzer ohne Sonderrechte, zwei Socket-Aufrufe in einen Wettlauf zu versetzen, um den Kernel zum Absturz zu bringen oder Root-Rechte zu erlangen.
• Ein Exploit, der einen Server zwölfmal zum Absturz brachte, verschafft nun Root-Rechte unter EL 8, 9 und 10.
• Red Hat hat keinen festen Kernel für RHEL 7, 8, 9 oder 10 und nennt keine Abhilfemaßnahmen.
• Die „rebootless“-Patches von KernelCare sind nun für RHEL, AlmaLinux sowie CloudLinux 8 und 9 und Debian 12 und 13 verfügbar.

Die Kurzfassung

Zur Langfassung springen ↓

Was ist passiert: Am 6. Oktober 2026 hat das Kernel-CVE-Team veröffentlicht: CVE-2026-98276, ein „Use-after-free“-Fehler bei UDP-Sockets, verursacht durch einen Wettlauf zwischen bind() und sock_gettstamp(), der Handler, der einem Programm mitteilt, wann das letzte Paket eines Sockets eingegangen ist. Jeder lokale Benutzer, der einen UDP-Socket öffnen kann, kann ihn auslösen, aber er ist über das Netzwerk nicht erreichbar. Am 4. November wurde ein funktionierender Exploit gegen einen CloudLinux-8-Server eingesetzt und hat es 12 Mal zu Schrott gefahren. Zu diesem Abschnitt springen → (So sah der Angriff auf einem echten Server aus) . TuxCare hat inzwischen anhand des von diesem Server wiederhergestellten Codes einen funktionierenden Root-Exploit entwickelt.

Wer ist betroffen: Jeder Kernel, der den Fix noch nicht übernommen hat – und das betrifft nach wie vor zahlreiche Produktionssysteme. Dazu gehören RHEL 7, 8, 9 und 10 sowie die auf dem Red Hat-Kernel basierenden Varianten, darunter CloudLinux 8, 9 und 10. Shared Hosting ist dabei der Schwachpunkt, da Kunden dort häufig ihren eigenen Code auf einem Kernel ausführen können, der von allen gemeinsam genutzt wird. Zu diesem Abschnitt springen →

Der aktuelle Stand:Es handelt sich nicht um einen Zero-Day. Der Fix war bereits im Upstream und in den stabilen Upstream-Zweigen vorhanden, bevor jemand einen Angriff meldete, und es ist kein Exploit-Code öffentlich zugänglich. TuxCare hat nun eine Rechteausweitung unter EL 8, 9 und 10 bestätigt, einschließlich des neuesten AlmaLinux 8-Kernels; behandeln Sie dies dort daher als lokales Root-Recht. Bei EL 7 geht TuxCare davon aus, dass es sich lediglich um einen Absturz handelt. Debian hat die Kernel behoben, Ubuntu, Oracle und Amazon haben einige behoben, und Red Hat hat noch keinen Fix für irgendeine EL-Version bereitgestellt oder einen Termin genannt. Die Patches von KernelCare, die keinen Neustart erfordern, sind für RHEL, AlmaLinux sowie CloudLinux 8 und 9 im Einsatz, und für EL 10 befinden sie sich im Test-Feed. Zu diesem Abschnitt springen →

Was heute zu tun ist: Es gibt weder eine sysctl-Einstellung, die man umschalten könnte, noch eine Firewall-Regel, die Abhilfe schafft – daher ist das Installieren des Patches die einzige wirkliche Lösung. Auf RHEL, AlmaLinux sowie CloudLinux 8 und 9 sowie Debian 12 und 13 können KernelCare-Nutzer den Patch ab sofort herunterladen:

kcarectl --update

Dann überprüfe es mit kcarectl --patch-info | grep 'CVE-2026-98276'. Auf EL 10, einschließlich CloudLinux 10, befindet sich der Patch derzeit im Test-Feed; fügen Sie daher dem Update-Befehl „–prefix test“ hinzu. Bis der Patch verfügbar ist, sollten Sie lokale Konten, denen Sie nicht vertrauen, einschränken oder sperren. Zu diesem Abschnitt springen →

Lokale Denial-of-Service-Schwachstellen landen in der Regel ganz unten auf der Prioritätenliste. Der Angreifer benötigt einen Zugang zum Rechner, das übliche Ergebnis ist ein Absturz und ein Neustart, und die meisten IT-Abteilungen haben dringlichere Probleme zu lösen. CVE-2026-98276 sah zunächst wie eine solche Schwachstelle aus, blieb aber nicht lange dort.

Jemand hat es bereits benutzt. Am 4. November, Ein CloudLinux-8-Server ist 12 Mal ausgefallen aus einem funktionierenden Exploit für diesen Fehler und mit kernel.panic_on_oops = 1 Einmal festgelegt, bedeutete jeder Absturz einen vollständigen Neustart. Zwei Tage später hatte TuxCare Root-Rechte auf AlmaLinux 8 mit einem Exploit, der aus dem von diesem Server wiederhergestellten Code erstellt wurde, und die Rechteausweitung funktioniert nun auf EL 8, 9 und 10. Und es gibt nichts, was man deaktivieren könnte. Der anfällige Code befindet sich hinter einem ioctl-Befehl mit Zeitstempel, den jeder Prozess für jeden von ihm geöffneten UDP-Socket aufrufen kann.

Auch die Kernel der Anbieter hinken hinterher. Der Fix war bereits vor der Veröffentlichung der CVE am 6. Oktober im Upstream verfügbar, Debian hat bereits vor Wochen korrigierte Kernel bereitgestellt, und Red Hat führt RHEL 7 bis 10 weiterhin als betroffen auf – ohne korrigierten Kernel und ohne Angabe eines Datums.

Wie eine Zeitstempelabfrage einen aktiven Socket freigibt

SIOCGSTAMP und SIOCGSTAMPNS, sowie die _NEW Die Versionen, die neuere Kernel für die 64-Bit-Zeit verwenden, sind alte, unscheinbare ioctls. Ein Programm ruft eines davon über einen Socket auf, um zu erfragen, wann das letzte Paket angekommen ist, und der Kernel antwortet über sock_gettstamp() in net/core/sock.c. Wenn zum ersten Mal eine Abfrage für einen Socket erfolgt, aktiviert der Handler außerdem die Zeitstempelung, indem er die SOCK_TIMESTAMP ein bisschen sk->sk_flags.

Das Problem ist nur, dass dies geschieht, ohne die Steckschlüsselverriegelung zu betätigen, und der Helfer darunter verwendet __set_bit(), was nicht atomar ist. Die CPU liest das gesamte Flags-Wort, fügt ein Bit per OR-Verknüpfung hinzu und schreibt das gesamte Wort zurück. Sollte sich zwischen dem Lesen und dem Schreiben ein anderes Bit in diesem Wort ändern, geht diese Änderung verloren.

Dieser andere Autor ist bind(). Beim Binden eines UDP-Sockets, udp_lib_get_port() Sätze SOCK_RCU_FREE und fügt den Socket zur Hash-Tabelle hinzu, wo der UDP-Empfangspfad ihn finden kann, ohne eine Sperre zu setzen. SOCK_RCU_FREE Das ist das Versprechen des Kernels an diese „lockless“ Leser. Wenn der Socket geschlossen wird, wartet der Kernel eine RCU-Gnadenfrist ab, bevor er ihn freigibt, damit jeder, der noch darauf zugreift, seinen Vorgang abschließen kann.

Läuft man die beiden auf verschiedenen CPUs, kann es zu einer schlechten zeitlichen Abstimmung kommen. Der ioctl-Aufruf liest die Flags kurz bevor bind() Sätze SOCK_RCU_FREE, schreibt dann aber seine veraltete Kopie zurück, nachdem der Socket bereits in der Tabelle steht. Das Flag ist verschwunden, aber der Socket ist für „lockless“-Leser weiterhin sichtbar, und nichts im Kernel weiß, dass das Versprechen gebrochen wurde. Schließt man ihn, während ein Paket gerade empfangen wird, gibt der Kernel den Speicher sofort frei, obwohl der Empfangspfad ihn noch nutzt. Das ist das „Use-after-free“-Problem.

Die Korrektur von Eric Dumazet nimmt die Stecknuss-Verriegelung auf sock_gettstamp(), aber nur, wenn SOCK_TIMESTAMP muss tatsächlich eingestellt werden, damit der gemeinsame Pfad ungesperrt bleibt. Der CVE-Eintrag Der Bericht wird Jungwoo Lee und Wongi Lee zugeschrieben, und die darin zitierten KASAN-Daten stammen aus einem Testprogramm, das die Reporter nannten. exploit.

In derselben Commit-Meldung wird darauf hingewiesen, dass sk_set_memalloc() und sk_clear_memalloc() ebenfalls ändern sk_flags ohne die Sperre. Ihre Aufrufer (nbd, iSCSI, NVMe over TCP, sunrpc und WireGuard) müssen zunächst einer Überprüfung unterzogen werden, daher plant das Upstream-Team einen separaten Patch. Das ist eine separate Korrektur, die zu einem späteren Zeitpunkt erfolgt und nicht Teil dieser CVE ist.

Jeder Kernel ohne diesen Fix weist das Problem weiterhin auf, und viele im Einsatz befindliche Unternehmenskernel haben den Fix noch nicht übernommen.

Auf dem angegriffenen Server lief ein CloudLinux-8-Kernel, und jeder Absturz hinterließ dieselben Spuren im Kernel-Protokoll. Zunächst erschienen Warnungen in den Zeilen 153 und 156 von net/ipv4/af_inet.c, innen inet_sock_destruct(), der Code, der einen Socket schließt. Dann folgte eine Dereferenzierung eines NULL-Zeigers, entweder in udp_destruct_common() als sich die Buchse schloss oder in __sk_mem_raise_allocated() aufgerufen von __udp_enqueue_schedule_skb() während ein Paket in die Warteschlange gestellt wurde. Beides ist genau das, was man erwarten würde, wenn der Schließpfad und der Empfangspfad um einen Socket konkurrieren, der bereits nicht mehr vorhanden ist.

Der Server hatte kernel.panic_on_oops = 1, was in vielen Hosting-Umgebungen zum Einsatz kommt, damit ein fehlerhafter Kernel neu startet, anstatt weiterzulaufen. Dadurch führte jeder „Oops“ zu einem Neustart – insgesamt zwölf Mal. Auf diesem Server wurde niemals Root-Zugriff gewährt, es gab lediglich die Abstürze, und in der Öffentlichkeit ist kein Exploit-Code aufgetaucht.

Falls ein Server ohne ersichtlichen Grund immer wieder neu gestartet wird, überprüfen Sie das Kernel-Protokoll des letzten Startvorgangs auf diese Funktionsnamen. Dazu ist ein persistentes Journal erforderlich:

journalctl -k -b -1 | grep -E 'inet_sock_destruct|udp_destruct_common|__sk_mem_raise_allocated|__udp_enqueue_schedule_skb'

Eine Übereinstimmung ist für sich genommen noch kein Beweis für einen Angriff, aber bei einem nicht gepatchten Kernel ist sie ein guter Grund, zu überprüfen, wer angemeldet war und welche Prozesse ausgeführt wurden.

Vom Absturzfehler zum Root-Fehler

Das Kernel-CVE-Team stuft CVE-2026-98276 mit 7,8 als „Hoch“ ein, mit einem lokalen Angriffsvektor, geringer Angriffskomplexität, geringen Berechtigungen und hohen Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Red Hat stuft die Schwachstelle mit 7,0 als „Moderate“ ein, und auch SUSE und Amazon kommen auf 7,0. Der gesamte Unterschied liegt in der Angriffskomplexität, die diese Anbieter als hoch einstufen, da der Angreifer ein Wettrennen gewinnen muss. Das ist auf dem Papier ein berechtigter Einwand, doch der Vorfall mit CloudLinux 8 zeigt, dass dieses Wettrennen auf einem Produktionsserver immer wieder zu gewinnen ist.

Die größere Lücke bestand zwischen der Punktzahl und den Beweisen, und diese Lücke hat sich nun geschlossen. Der 7,8-Vektor geht davon aus, dass ein „Use-after-free“-Socket wie dieser zu einer Rechteausweitung genutzt werden kann, und TuxCare hat dies nun geschafft. Das Team erlangte Root-Rechte auf AlmaLinux 8 mit dem Standard-Kernel, indem es einen Exploit nutzte, der aus dem vom angegriffenen Server wiederhergestellten Code erstellt wurde, und hat seitdem die Rechteausweitung auf EL 8, 9 und 10 bestätigt. Dazu gehört auch der neueste AlmaLinux-8-Kernel, 4.18.0-553.184.1.el8_10. Der Exploit ist nicht hundertprozentig zuverlässig, hat aber bereits mehrfach funktioniert. Bei EL 7 geht TuxCare von einem rein lokalen Systemabsturz aus. Bei allen anderen Versionen der EL-Familie sollte dies als lokaler Root-Zugriff behandelt und mit höherer Priorität eingestuft werden, als es die Herstellerbewertung von 7,0 nahelegt.

CloudLinux 9 und 10 laufen mit AlmaLinux-Kerneln, daher folgen sie der AlmaLinux-Reihe. Bei Ubuntu hängt der Status von der jeweiligen Kernel-Variante ab; überprüfen Sie daher lieber das tatsächlich von Ihnen verwendete Paket als die Versionsnummer. Wenn Sie Ihre eigenen Kernel kompilieren, ist der Fehler in jeder der oben genannten stabilen Versionen behoben.

Ältere Versionen, die unter den „Endless Lifecycle Support“ von TuxCare fallen, sind in einem besseren Zustand, als man vielleicht vermuten würde. ELS-Kernel mit diesem Fix wurden zwischen dem 14. und 26. Oktober für CentOS 6, Oracle Linux 6, CentOS 8.5 und Ubuntu 20.04 sowie als Kernel mit erweitertem Support für AlmaLinux 9.2 und 9.6 bereitgestellt.

Bei den meisten Kernel-Fehlern gibt es eine Einstellung, die man anpassen kann, während der Patch noch in Arbeit ist – ein Modul, das man entladen kann, oder einen sysctl-Schalter, den man umlegen kann. Bei diesem Fehler gibt es nichts dergleichen. sock_gettstamp() Es handelt sich um Kernel-Socket-Code, und es gibt weder eine sysctl-Einstellung noch eine Boot-Option, mit der man ihn deaktivieren kann. Jeder normale Benutzer, der einen UDP-Socket erstellen kann, kann darauf zugreifen, und bei einer Standardinstallation sind das alle.

Eine Firewall hilft hier nicht weiter. Auslöser sind einige Systemaufrufe an einem Socket, über den der Angreifer die Kontrolle hat, und diese werden weder von iptables noch von nftables abgefangen.

Eine SELinux-Richtlinie könnte die ioctl-Aufrufe für Zeitstempel blockieren. Unter CloudLinux muss SELinux jedoch für cPanel & WHM deaktiviert sein, sodass diese Option für viele Hosting-Server nicht in Frage kommt.

Nun geht es darum, einzuschränken, wer auf dem Host Code ausführen darf. Bei Shared Hosting umfasst dies den Shell-Zugriff, Cron-Jobs und alle Kundenanwendungen, die ihre eigenen Binärdateien ausführen können. Schränken Sie Konten, denen Sie nicht vertrauen, ein oder sperren Sie sie, bis der Patch installiert ist, und achten Sie auf unerklärliche Neustarts – wobei Sie bedenken sollten, dass Ihnen möglicherweise nur die fehlgeschlagenen Versuche angezeigt werden. Installieren Sie anschließend den Patch.

Der rebootless-Patch von KernelCare übernimmt den Upstream-Fix unverändert und nutzt dabei die Socket-Sperre rund um die Aktualisierung des Flags. Es handelt sich um eine kleine Änderung ohne Änderungen an der Datenstruktur, wodurch sie sich ideal für einen rebootless-Patch eignet. Der Patch wird für die gesamte EL-Familie bereitgestellt, während Red Hat noch keinen korrigierten Kernel für irgendeine EL-Version bereitstellt. LibCare ist hier nicht beteiligt, da es sich um einen Kernel-Fehler handelt.

EL 7 bildet hier eine Ausnahme. TuxCare geht davon aus, dass es sich um einen lokalen Absturz ohne Privilegieneskalation handelt, daher ist nicht geplant, diesen vor Red Hat zu beheben. Überall dort, wo ein Patch bereits im Einsatz ist, erhalten Hosts mit automatischen KernelCare-Updates diesen gemäß ihrem normalen Zeitplan, oder Sie können ihn sofort mit `kcarectl –update` abrufen. Unter EL 10, einschließlich CloudLinux 10, befindet sich der Patch derzeit im Test-Feed; verwenden Sie daher „kcarectl –update –prefix test“. In beiden Fällen ist kein Neustart erforderlich. Vergewissern Sie sich anschließend, dass der Patch tatsächlich installiert wurde:

kcarectl --patch-info | grep 'CVE-2026-98276'

Wenn dabei nichts angezeigt wird, hat KernelCare noch keinen Patch für diese CVE bereitgestellt. Überprüfen Sie daher, ob auf dem Host bereits ein korrigierter Hersteller-Kernel läuft, bevor Sie davon ausgehen, dass er angreifbar ist. Der TuxCare CVE Tracker zeigt den Status der Patches, die ohne Neustart installiert werden können, für jede Distribution in Echtzeit an.

Holen Sie sich KernelCare noch heute →

Ein paar Zeilen Code zum Sperren und eine lange Wartezeit

Die Korrektur im Upstream-Code umfasst nur wenige Zeilen, und RHEL-Benutzer haben nach wie vor keinen Hersteller-Kernel zur Installation.

Nach den üblichen Maßstäben hätte das eigentlich niemandem auffallen dürfen. Der Patch wurde noch vor der CVE-Veröffentlichung bereitgestellt, die CVE wurde einen Monat vor dem ersten Angriff veröffentlicht, und es ist kein Exploit-Code öffentlich zugänglich. Auf dem Papier hat ein lokaler Absturzfehler mit einer Herstellerbewertung von 7,0 keine Priorität.

Dann tauchte ein funktionierender Exploit auf einem Produktions-Hosting-Server auf, während für die Kernel der RHEL-Familie, auf denen viele Hosting-Server laufen, noch immer kein Hersteller-Patch vorliegt. Innerhalb von zwei Tagen war aus eben diesem Exploit-Code ein Root-Exploit geworden. Shared Hosting kommt einem Worst-Case-Szenario für einen lokalen Fehler sehr nahe. Zahlreiche Kunden können unter einem lokalen Konto ihren eigenen Code ausführen, und es reicht schon einer von ihnen, um den Host lahmzulegen oder zu übernehmen – mit Folgen für alle anderen darauf.

Wenn Sie also Multi-Tenant-Server betreiben, stufen Sie diese Schwachstelle nicht als lokalen DoS-Angriff ein. Bei EL 8 bis 10 handelt es sich um einen lokalen Root-Zugriff. Überprüfen Sie die Protokolle auf die Absturzsignatur, schränken Sie die Rechte von Konten ein, denen Sie nicht vertrauen, und installieren Sie den Patch – entweder als Patch ohne Neustart, sofern verfügbar, oder durch einen Neustart in einen korrigierten Kernel, sofern Ihre Distribution einen solchen bereitstellt.

Holen Sie sich KernelCare noch heute →

Wie es sich zugetragen hat

Quellen

Als Hauptquellen für diesen Beitrag dienen die CVE-Meldung zum Kernel, der CVE-Eintrag und der Upstream-Fix sowie die Seiten der Anbieter Red Hat (einschließlich des Bug-Trackers), Debian, Ubuntu, SUSE, Amazon und Oracle. Ebenfalls zitiert werden der Vorfallbericht von CloudLinux, der NVD-Eintrag, der OSV-Eintrag sowie die KernelCare- und ELS-Release-Einträge von TuxCare vom 9. November 2026.