Linux TCP Use-After-Free: Patchen oder Mitigieren?

Dein Kernel enthält ein aus der Ferne erreichbares Use-after-free im TCP-Handshake-Pfad, dein Distributor hat noch keinen Fix ausgeliefert, und jemand hat bereits einen funktionierenden Root-Exploit demonstriert. Also, was ist der Plan: abwarten oder schon mal Pakete an der Firewall verwerfen? Der als CVE-2026-98432 veröffentlichte Linux-TCP-Use-after-free ist ein sauberes Beispiel für die älteste Entscheidung im Security-Betrieb, nämlich patchen oder mitigieren. Die ehrliche Antwort lautet, dass die beiden Optionen überhaupt nicht gleichwertig sind. Nur eine davon behebt das Problem tatsächlich.

Ich saß schon auf beiden Seiten dieser Entscheidung. Ich habe einen Notfall-Kernel-Rollout aufgeschoben, weil die Mitigation auf dem Papier gut genug aussah, und ich habe auch zugesehen, wie eine „temporäre“ Firewall-Regel acht Monate lang still in Produktion vor sich hin gammelte, während alle die CVE vergessen hatten, die sie überdecken sollte. Dieser Bug eignet sich gut, um zu besprechen, wann welcher Ansatz gewinnt, denn die Abwägungen sind hier ungewöhnlich gut nachvollziehbar.

Was das TCP-Use-after-free eigentlich ist

Die Mechanik ist wichtig, weil sie bestimmt, was eine Mitigation leisten kann und was nicht. Wenn dein Server eine IPv4-TCP-Verbindung annimmt, verfolgt der Kernel den halb offenen Handshake in einem leichtgewichtigen Request-Socket und befördert ihn zu einem vollwertigen Socket, sobald der Handshake abgeschlossen ist. Enthielt der IPv4-Header der Gegenstelle Optionen, speichert der Kernel sie, um sie in seinen Antworten zurückzuspiegeln. Der Bug: Der Kernel übergab diese gespeicherten Optionen an die neue Verbindung, ohne sie zu kopieren, und gab sie dann sofort frei, obwohl eine andere CPU sie noch lesen konnte, um eine Handshake-Antwort zu bauen. Das ist ein Use-after-free, erreichbar durch einen entfernten, nicht authentifizierten Peer, noch bevor auch nur eine Zeile deines Anwendungscodes läuft.

Der Upstream-Fix von Eric Dumazet umfasst vier Zeilen: Zwei einfache kfree()-Aufrufe werden durch kfree_rcu() ersetzt, das die Freigabe aufschiebt, bis jeder Leser mit dem Speicher fertig ist. Das ist der kanonische Kernel-Fix für genau diese Fehlerklasse. Leser unter RCU halten Referenzen, die du nicht sehen kannst, also lässt du die Grace Period ablaufen, bevor du den Speicher zurückholst. Der eigene CNA des Kernels hat es mit CVSS 9.8 bewertet. Red Hat hat es zunächst mit 8.1 eingestuft und am 30. Oktober auf 9.8 (Critical) angehoben, mit Verweis auf das Fehlen von Netzwerkvoraussetzungen.

Zwei Details verändern die Risikorechnung. Erstens: Das Rennen endet glimpflich. Ein fehlgeschlagener Versuch lässt den Handshake einfach scheitern, ohne dass die Kiste in Panik gerät, sodass ein Angreifer beliebig oft wiederholen kann. Zweitens zielt der von Anthropic demonstrierte Exploit-Pfad auf Hosts mit einem Multipath-TCP-Listener. Laut dem Go Security Team öffnen Go-Programme unter Linux seit Go 1.24 standardmäßig MPTCP-Listener, sofern der Kernel das zulässt. Prüf deine Flotte:

ss -Mlnp                 # MPTCP listeners and their owning processes
sysctl net.mptcp.enabled # 1 means apps may open MPTCP sockets

Eine leere Ausgabe von ss -M bedeutet, dass kein MPTCP-Listener läuft. Wieg dich aber nicht in Sicherheit. Das Go-Team stellt klar, dass der zugrunde liegende Bug nicht MPTCP-spezifisch ist. Es ist ein generisches UAF in der Handshake-Verarbeitung, und MPTCP ist nur der Pfad, dessen Ausnutzung end-to-end bewiesen wurde.

Der Patch-Weg: Kernel fixen, neu starten, fertig

Patchen ist langweilig zu beschreiben, weil es die einzige Option ist, die die Verwundbarkeit tatsächlich beseitigt, statt sie nur umzubauen. Gefixte Kernel wurden am 11. und 15. Oktober upstream für alle gepflegten Stable-Linien veröffentlicht, und der Bug reicht bis Linux 4.4 zurück. Das heißt, viele Langzeitsysteme sind betroffen, auch solche mit Kerneln, die upstream nicht mehr angefasst werden.

Der Haken ist der Neustart. Ein Kernel-Update bringt nichts, solange die Maschine nicht in den neuen Kernel bootet, und genau dort steckt der eigentliche operative Aufwand: geleerte Kubernetes-Nodes, Failover-Proben, der Datenbank-Primary, den niemand während der Geschäftszeiten neu starten will. Deshalb ist „einfach patchen“ als Ratschlag immer richtig und nie ausreichend. Du brauchst einen Rollout-Plan: zuerst Canary-Hosts, dann zustandslose Schichten, dann die zustandsbehafteten mit Wartungsfenstern. Wenn du schon einmal einen flottenweiten Notfall-Kernel-Wechsel durchgezogen hast, kennst du den Ablauf. Die Teams, die das gut hinbekommen, haben das Drainen von Nodes geübt, als noch nichts brannte. Die Gewohnheiten defensiver Technik, die du an ruhigen Dienstagen aufbaust, zahlen sich bei einem 9.8 aus.

Eine Falle sollte man beim Namen nennen: dpkg -l oder rpm -q kernel mit einem gefixten Paket bedeutet nichts, wenn der laufende Kernel älter ist. uname -r zeigt dir, was tatsächlich läuft. Auf RHEL-artigen Systemen verrät needs-restarting -r klar, ob ein Neustart aussteht. Ich habe Post-Incident-Berichte gelesen, in denen die „gepatchte“ Flotte eine Flotte aus installierten, aber nicht laufenden Kerneln war. Prüfe die laufende Version gegen den Tracker deines Distributors, nicht gegen die Upstream-Nummer, denn Distro-Kernel tragen Backports unter eigener Versionierung.

Der Mitigation-Weg: IPv4-Optionen verwerfen, MPTCP deaktivieren

Die veröffentlichte Zwischenlösung ist eine nftables-Regel, die eingehende IPv4-TCP-Pakete mit IP-Optionen verwirft, also die Auslösebedingung für den verwundbaren Pfad. Ergänzen kannst du das, indem du MPTCP deaktivierst (sysctl -w net.mptcp.enabled=0), falls du es nicht nutzt. Beides ist schnell, ohne Neustart umsetzbar und lässt sich mit Configuration Management an einem Nachmittag ausrollen. Das ist der Reiz.

Jetzt der Teil, der deine Begeisterung dämpfen sollte: Red Hats eigenes Advisory sagt, die Regel „reduziert die Exposition gegenüber dieser Schwachstelle, kann sie aber nicht vollständig verhindern“. Lies den Satz zweimal. Die Mitigation verkleinert die Angriffsfläche, sie schließt sie nicht. Pakete mit IP-Optionen sind im normalen Verkehr selten. Die meisten Middleboxen verwerfen sie ohnehin, was ein Grund dafür ist, dass Ausnutzung über das offene Internet als unwahrscheinlich gilt. Aber „selten“ und „unmöglich“ sind verschiedene Wörter, und der Bug steckt im generischen Handshake-Code, nicht nur in dem Options-Pfad, den jemand zufällig getestet hat.

Es gibt außerdem einen subtileren Preis: Mitigationen erzeugen ein falsches Gefühl von Abschluss. Das Ticket wird auf „so gut wie erledigt“ verschoben, die Dringlichkeit verpufft aus dem Patch-Vorhaben, und sechs Wochen später läufst du immer noch einen verwundbaren Kernel hinter einem Paketfilter, während die Erinnerung daran, warum das überhaupt nötig war, verblasst. Ich habe dieses Muster schon einmal im Zusammenhang mit dem kritischen CVE-Fenster bei PHP beschrieben. Dort standen die Teams besser da, die das verwundbare Ding einfach offline nahmen, als die, die clevere Filter stapelten. Gleiche Lektion, anderer Stack.

Patchen oder Mitigieren: Wann welche Option gewinnt

Hier ist meine ehrliche Bewertung, nach Jahren, in denen ich diese Entscheidung unter Druck treffen musste.

• Gefixter Kernel ist für deinen Distributor verfügbar. Patchen gewinnt eindeutig. Debian, SUSE Enterprise, Oracle UEK und Amazon Linux haben alle Fixes ausgeliefert. Keine Mitigation ist cleverer als ein vier Zeilen langer Upstream-Fix. Plane die Neustarts, roll in Ringen aus und mach weiter.
• Noch kein gefixter Kernel, das Risiko ist real. Sofort mitigieren, genau dafür sind Mitigationen da. Ubuntu und RHEL waren Ende Oktober noch „Vulnerable“/betroffen. Wenn du aus dem Internet erreichbar bist und einen MPTCP-Listener betreibst, verwirf IP-Options-Pakete und deaktiviere MPTCP noch heute, und verfolge den gefixten Kernel wie ein Release, auf das du gerade wartest.
• Aus dem Internet erreichbar, aber hinter einem verwalteten Eingang. Die Dringlichkeit sinkt. Die Einschätzung von AWS, dass Traffic, der über deren Load Balancer, CloudFront oder API Gateway läuft, deine Instanzen nicht als rohes, unvertrauenswürdiges TCP erreicht, ist plausibel. Mitigiere trotzdem (es ist billig) und patche im regulären Zyklus statt in einem Notfallzyklus.
• Single-Core- oder Single-Queue-Systeme. Geringere Priorität. Das Rennen braucht parallele Paketverarbeitung auf mehreren CPUs. Eingebettete Systeme und winzige VMs bekommen etwas Luft, sind aber oft genau die Kisten, die niemand je neu startet. Lass also aus „niedrige Priorität“ kein „nie“ werden.
• Kernel ohne Support (Upstream vor 5.10). Mitigation ist deine einzige Option, die nicht vom Upstream abhängt. Hier gewinnen Mitigationen tatsächlich, denn die Alternative ist ein Vendor-Backport, der vielleicht nie kommt. Es ist außerdem ein deutliches Signal, dass die Kiste selbst die Schwachstelle ist, und die echte Lösung besteht darin, sie zu ersetzen.

Die Distro-Lücke ist die eigentliche Geschichte

Was dich beunruhigen sollte, ist nicht der Bug. Use-after-free-Fixes mit vier Zeilen landen jeden Monat in den Stable-Kerneln. Beunruhigend ist, dass zwei der größten Server-Distributionen der Welt, Ubuntu und RHEL, mehr als zwei Wochen nach dem Upstream noch ohne ausgelieferte Fixes dastanden, während Amazon Linux alle seine Kernel gepatcht hatte und AlmaLinux, ein Community-Rebuild, gefixte Kernel im Test schon vor dem Upstream hatte. Die HN-Kommentatoren haben das bemerkt und sind zu Recht verärgert: Das sind die Distributionen, die sich am lautesten als serverbereit vermarkten.

Für Praktiker ist die Schlussfolgerung unspektakulär: Dein Expositionsfenster wird durch die Backport-Pipeline deines Anbieters bestimmt, nicht durch den Upstream. Daraus folgen zwei Dinge. Erstens: Kenne die Tracker-URLs deiner Distribution und beobachte sie tatsächlich. Diese CVE stand bei NVD auf „Received“ ohne Analyse, während CNA des Kernels, Red Hat und die Distributionen längst ausführliche Seiten hatten. Zweitens: Behandle die Reaktionsgeschwindigkeit der Distribution als Auswahlkriterium. Amazon Linux hat gerade gezeigt, dass seine Kernel-Fix-Pipeline deutlich schneller ist als die der beiden etablierten Anbieter. Das spielt in einer Marketingpräsentation keine Rolle, aber am Halloween-Wochenende, wenn eine 9.8 auftaucht, schon.

Der KI-geschriebene Exploit verändert die Uhr

Die folgenreichste Zeile in der Veröffentlichung überliest man leicht: Anthropic berichtet, dass sein Modell Claude einen funktionierenden Remote-Root-Exploit erzeugt hat, nach einer initialen Aufforderung und mit weniger als einer Stunde Maschinenzeit vom Kernel-Pointer-Leak bis zur Root-Shell. Sie haben ihn nicht veröffentlicht, und die Skeptiker auf HN haben sich über den Rahmen „vertrau mir, Bro“ amüsiert. Zu Recht. Aber selbst mit Marketing-Abschlag ist die Richtung eindeutig: Die Zeit zwischen „Diff landet im Stable-Tree“ und „funktionierender Exploit existiert“ schrumpft, weil der Engpass beim Exploit-Schreiben nie der Bug war, sondern der Mensch, der den Diff lesen und das Heap-Grooming machen konnte.

Das verkürzt das Entscheidungsfenster zwischen Patchen und Mitigieren. Als die Exploit-Entwicklung Wochen dauerte, war „jetzt mitigieren, beim nächsten Wartungsfenster patchen“ vertretbar. Wenn ein Modell über Nacht aus einem öffentlichen Commit einen PoC herausarbeiten kann, muss deine Mitigationsphase in Stunden gemessen werden und deine Patchphase in Tagen. Der Vier-Zeilen-Fix ist öffentlich. Jeder kann ihn studieren. Geh davon aus, dass der Exploit es auch ist.

Meine Empfehlung

Patchen. Mitigieren nur als Brücke, und dieser Brücke ein Ablaufdatum geben. Konkret: Wenn dein Distributor einen gefixten Kernel hat, rolle ihn jetzt aus und prüfe uname -r nach jedem Neustart. Wenn du auf Ubuntu oder RHEL bist, deploye heute die Verwerfung der IP-Optionen und deaktiviere MPTCP, und behandle den fehlenden Kernel-Fix als blockierende Abhängigkeit. Prüfe den Tracker täglich, nicht wöchentlich. Priorisiere alles, was aus dem Internet erreichbar ist und einen MPTCP-Listener hat, dann alles andere, das eingehende TCP-Verbindungen annimmt, also praktisch alles. Container retten dich nicht, denn sie teilen sich den Host-Kernel. Patche also die Nodes.

Die tiefere Lehre ist die, die dieser Bug alle paar Jahre unter einer neuen CVE-Nummer wiederholt: Mitigationen kaufen Zeit, aber nur Patches schließen Lücken, und die Zeit, die Mitigationen kaufen, wird immer kürzer. Bau die Routine für schnelle, sichere Kernel-Rollouts auf, bevor du sie brauchst, denn der nächste Vier-Zeilen-Fix liegt schon in jemandes Warteschlange.