{"id":1406,"date":"2026-10-31T10:19:23","date_gmt":"2026-10-31T09:19:23","guid":{"rendered":"https:\/\/www.cisilino.com\/?p=1406"},"modified":"2026-10-31T10:23:27","modified_gmt":"2026-10-31T09:23:27","slug":"linux-kernel-schwachstelle-tcp-cve-2026-98432","status":"publish","type":"post","link":"https:\/\/www.cisilino.com\/de\/2026\/10\/31\/linux-kernel-schwachstelle-tcp-cve-2026-98432\/","title":{"rendered":"Linux-Kernel-Schwachstelle: ein Use-after-free im TCP IPv4"},"content":{"rendered":"\n

Ich verwalte seit Jahren Debian-Server im produktiven Einsatz. Jedes Mal, wenn eine neue CVE zum Kernel erscheint, halte ich an und lese mir die Details durch. Dann entscheide ich, ob ich sofort aktualisiere oder warte. Dieses Mal ist die Geschichte verzwickter als sonst: Es gibt eine Schwachstelle im Linux-Kernel<\/strong> im TCP-IPv4-Code, einen zwischen den Herstellern umstrittenen CVSS-Score, und sogar einen angeblichen Root-Exploit, der von einer k\u00fcnstlichen Intelligenz gebaut wurde. Fangen wir mit einer Frage an, die nebens\u00e4chlich wirkt, es aber nicht ist: Was ist MPTCP, und warum ist es wichtig, selbst wenn du es nicht nutzt?<\/p>\n\n\n\n

\"Schwachstelle<\/figure>\n\n\n\n

Was ist MPTCP, und warum betrifft es auch dich, wenn du es nicht nutzt<\/h2>\n\n\n\n

Multipath TCP (MPTCP) ist der Standard RFC 8684. Er erweitert das klassische TCP, damit eine einzelne Verbindung gleichzeitig \u00fcber mehrere Netzwerkpfade laufen kann. Ein Smartphone kann WiFi und Mobilfunk im selben Moment nutzen, f\u00fcr dieselbe Verbindung. Ein Server mit mehreren Schnittstellen kann dasselbe tun, f\u00fcr Redundanz oder um Bandbreite zu summieren. Apple nutzt es produktiv schon seit iOS 7, im Jahr 2013, f\u00fcr Siri: das ist der bekannteste reale Anwendungsfall. Manche Mobilfunkanbieter, zum Beispiel in S\u00fcdkorea, setzen es f\u00fcr WiFi\/LTE-Bonding ein. Mehrere Rechenzentren nutzen es f\u00fcr Multihoming zwischen verschiedenen Uplinks. Im Linux-Mainline-Kernel ist es seit Version 5.6 enthalten.<\/p>\n\n\n\n

Der Punkt, der mich die Augenbraue hochziehen lie\u00df, ist ein anderer. Seit Version 1.24 verlangen in Go geschriebene Programme standardm\u00e4\u00dfig MPTCP f\u00fcr lauschende Sockets. Das Go Security Team hat das am 29. Oktober best\u00e4tigt. Gleichzeitig hat es eine unangenehme Warnung ausgesprochen: Der Bug, von dem wir heute sprechen, ist nicht MPTCP-spezifisch. Ein System ohne aktive MPTCP-Listener kann trotzdem \u00e4hnlichen Angriffen ausgesetzt sein. Der verwundbare Code liegt im generischen TCP-IPv4-Pfad, nicht in einem optionalen Modul. Man kann MPTCP pro Programm deaktivieren, mit der Variable GODEBUG=multipathtcp=0<\/code> zur Laufzeit. Doch das Go Security Team bezeichnet diese Abmilderung als \u201ebr\u00fcchig\u201c: Ein einziger verbleibender MPTCP-Listener reicht aus, um sie zunichtezumachen. Niemand hat bewiesen, dass jeder funktionierende Exploit tats\u00e4chlich von MPTCP abh\u00e4ngt. Deshalb bleibt der MPTCP-Code eine Angriffsfl\u00e4che, auch wenn du ihn in deinem Stack nie bewusst aktivierst: Es reicht, dass er in den Kernel compiliert und erreichbar ist.<\/p>\n\n\n\n

Das MPTCP-Projekt selbst erkl\u00e4rt auf seiner eigenen Seite, dass die wichtigsten aktuellen Linux-Distributionen den Kernel standardm\u00e4\u00dfig mit MPTCP-Unterst\u00fctzung compiliert ausliefern (CONFIG_MPTCP=y<\/code>). Es nennt ausdr\u00fccklich Debian, Ubuntu, RHEL und Fedora. Das ist eine Aussage des Projekts selbst, keine unabh\u00e4ngige \u00dcberpr\u00fcfung Distribution f\u00fcr Distribution, aber das Konzept bleibt g\u00fcltig: Die Unterst\u00fctzung ist auf Kernel-Ebene aktiviert, nicht \u201eopt-in\u201c auf Betriebssystemebene. Nur die Aushandlung pro einzelner Verbindung bleibt Aufgabe der Anwendung.<\/p>\n\n\n\n

Die Schwachstelle im Linux-Kernel CVE-2026-98432 im \u00dcberblick<\/h2>\n\n\n\n

Das CVE-Team des Linux-Kernels hat CVE-2026-98432 am 15. Oktober 2026 ver\u00f6ffentlicht. Der Upstream-Fix war bereits zehn Tage zuvor angewendet worden, am 5. Oktober. Es kommt h\u00e4ufig vor, dass die Ver\u00f6ffentlichung dem Commit mit einer gewissen Verz\u00f6gerung folgt. Der CVSS-Score von 9,8 (kritisch) kam erst am 24. Oktober, neun Tage nach der Ver\u00f6ffentlichung der CVE.<\/p>\n\n\n\n

Das Problem liegt in der Behandlung des TCP-Handshakes f\u00fcr IPv4, genauer in der Funktion tcp_v4_syn_recv_sock()<\/code>. Wenn eine Verbindung erstellt wird, werden die IP-Optionen des SYN-Pakets vom wartenden Request-Socket an den neuen Socket \u00fcbergeben. Zum Beispiel Record Route oder Timestamp, falls der Client sie in einem eigens konstruierten SYN einf\u00fcgt. Das Problem ist, dass sie per Referenz \u00fcbergeben werden, nicht per Kopie, und ohne das Lock des Listeners. Laut der technischen Analyse des Patches hei\u00dfen die betroffenen Strukturen inet_opt<\/code> und ireq_opt<\/code>. Eine zweite CPU kann diesen Puffer mit kfree()<\/code> freigeben, aufgerufen von inet_sock_destruct()<\/code> oder von tcp_v4_reqsk_destructor()<\/code>. W\u00e4hrenddessen liest eine erste CPU ihn noch in ip_options_build()<\/code>, um das SYNACK zu bauen. Es ist ein klassisches Use-after-free, verursacht durch eine Race Condition. Der entsprechende IPv6-Pfad, tcp_v6_syn_recv_sock()<\/code>, kopiert die Optionen statt sie per Referenz zu \u00fcbergeben: Er ist von der Haupt-Race nicht betroffen. Es gibt auch einen zweiten Angriffsweg, \u00fcber die Migration von Request-Sockets: net.ipv4.tcp_migrate_req=1<\/code> oder ein eBPF-Programm mit BPF_SK_REUSEPORT_SELECT_OR_MIGRATE<\/code>. Beide sind standardm\u00e4\u00dfig deaktiviert.<\/p>\n\n\n\n

Der Bug ist remote ausnutzbar und erfordert laut Einsch\u00e4tzung des Kernel-Teams weder Authentifizierung noch Benutzerinteraktion. Er ist seit Kernel-Version 4.4 vorhanden. Der Fix stammt von Eric Dumazet, gemeldet von Xinyang Ge von Anthropic. Er verschiebt die Freigabe des Speichers auf die Zeit nach einer RCU-Grace-Period, mit kfree_rcu()<\/code>: So kann keine CPU mehr einen bereits freigegebenen Puffer lesen. Die korrigierten stabilen Versionen sind 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und die Mainline ab 7.3-rc7.<\/p>\n\n\n\n

Widerspr\u00fcchliche CVSS-Scores: Nicht alle Hersteller sind sich einig<\/h2>\n\n\n\n

Hier wird die Geschichte komplizierter. Das Kernel-CVE-Team und Ubuntu bewerten die Angriffskomplexit\u00e4t als niedrig und vergeben 9,8 (kritisch). Oracle und SUSE vergeben dagegen 8,1 (wichtig): derselbe CVSS-Vektor, aber hohe Angriffskomplexit\u00e4t. Red Hat hat merkw\u00fcrdigerweise zwei Bewertungen, die nicht \u00fcbereinstimmen. Die \u00f6ffentliche CVE-Seite zeigt \u201eModerate, 5.9\u201c. Die maschinenlesbare Advisory-Datei, aktualisiert am 29. Oktober, zeigt dagegen \u201eImportant, 8.1\u201c, mit hoher Auswirkung auf Vertraulichkeit und Integrit\u00e4t. Am selben Tag hat der interne Bugtracker von Red Hat die Schwere von medium auf high angehoben. Amazon vergibt seinerseits 7,0. Zum Zeitpunkt, an dem ich das schreibe, hat die NVD noch keinen eigenen Score ver\u00f6ffentlicht.<\/p>\n\n\n\n

Das sollte man ehrlich sagen. Diese interne Unstimmigkeit bei Red Hat ist kein Detail, das ich selbst hergeleitet habe: Sie wird so vom Originalartikel von The Hacker News berichtet, meiner Hauptquelle f\u00fcr diese Daten. Es ist nicht das erste Mal, dass ein Hersteller f\u00fcr denselben Bug zwei unterschiedliche Zahlen auf unterschiedlichen Kan\u00e4len ver\u00f6ffentlicht. Aber hier sagt der Sprung von \u201emoderat\u201c zu \u201ewichtig\u201c am selben Tag viel aus. Auch f\u00fcr diejenigen, die den Code schreiben, ist es schwierig, die tats\u00e4chliche Ausnutzbarkeit einer Race Condition im Kernel mit Sicherheit einzusch\u00e4tzen.<\/p>\n\n\n\n

Patch-Status: Debian schon korrigiert, andere noch nicht<\/h2>\n\n\n\n

Das ist der Punkt, der mich am direktesten betrifft: Die Hosting-Umgebungen, die ich verwalte, laufen auf Debian Stable. Und hier sprechen die Fakten klar, ohne dass man etwas betonen m\u00fcsste: Debian hat diese Schwachstelle im Linux-Kernel bereits korrigiert<\/strong>, sowohl auf trixie als auch auf bookworm. Debian trixie (stable) wurde am 16. Oktober 2026 korrigiert, mit dem Paket linux 6.12.113-1<\/code>, Advisory DSA-6568-1. Debian 12 (bookworm) wurde in zwei Schritten korrigiert: am 17. und am 22. Oktober 2026, mit linux 6.1.190-1<\/code> (Advisory DLA-4841-1) und linux-6.12 6.12.113-1~deb12u1<\/code> (Advisory DLA-4850-1). In seiner eigenen Tracking-Tabelle listet Debian f\u00fcr diese CVE keinen eigenen CVSS-Score auf. Es markiert nur den Fix-Status f\u00fcr jedes Release: Das ist die Information, die wirklich z\u00e4hlt, f\u00fcr alle, die entscheiden m\u00fcssen, ob sie einen Server neu starten.<\/p>\n\n\n\n

Es hilft, das mit dem Status anderer weit verbreiteter Distributionen zu vergleichen, um der Sache Gewicht zu geben. Am 30. Oktober hat Red Hat den Status f\u00fcr RHEL 8, 9, 10 und OpenShift 4 aktualisiert. Zuvor war es \u201efix deferred\u201c (markiert am 29. Oktober), jetzt ist es \u201eaffected\u201c. Kein Ver\u00f6ffentlichungsdatum wurde mitgeteilt. Ubuntu gilt auf allen unterst\u00fctzten Versionen (22.04, 24.04, 26.04, 26.10) noch als \u201ein Bearbeitung\u201c, ohne Datum. Ubuntu 16.04, 18.04 und 20.04 gelten als verwundbar, ohne dass \u00fcberhaupt ein Fix aufgelistet ist. SUSE Linux Enterprise Server, von SP4 bis SP7 plus 16.0, befindet sich in derselben Lage. Oracle Linux (UEK), openSUSE Leap 16.0, SUSE Linux Micro 6.2 und Amazon Linux 2023 sind dagegen schon korrigiert. RHEL 7 ist nicht betroffen: Der verwundbare Codepfad wurde auf dieser Release nie ausgeliefert.<\/p>\n\n\n\n

Ich sage das nicht, um Ubuntu oder RHEL schlechtzumachen. Es bleiben seri\u00f6se Distributionen mit robusten Sicherheitsprozessen. Ich sage es, weil bei diesem einzelnen Bug, in diesem Zeitfenster, die Fakten so sind: Wer sich auf Hosting mit Debian Stable verl\u00e4sst, hat den Fix schon installiert. Auf anderen, stark genutzten Distributionen bleibt der Server dagegen f\u00fcr einen unbestimmten Zeitraum exponiert. Das ist ein konkreter, nachpr\u00fcfbarer Vorteil, wenn man sich die Daten ansieht. Es ist keine Meinung \u00fcber das Debian-Projekt im Allgemeinen.<\/p>\n\n\n\n

Der (berichtete, nicht unabh\u00e4ngig verifizierte) Exploit von Anthropic<\/h2>\n\n\n\n

Der ungew\u00f6hnlichste Teil dieser Geschichte betrifft Anthropic, das Unternehmen, das den Bug als erstes \u00fcber Xinyang Ge gemeldet hat. Laut Branchenberichten hat eines seiner internen KI-Modelle, nicht \u00f6ffentlich ver\u00f6ffentlicht, selbstst\u00e4ndig einen funktionierenden Root-Exploit gebaut. Ausgehend nur vom Patch und vom Report als Prompt. Der zweistufige Angriff w\u00fcrde so funktionieren. In der ersten Phase l\u00e4sst die Race den Angreifer zus\u00e4tzliche Bytes aus der Antwort des Kernels empfangen. Von dort gewinnt er eine Kernel-Adresse, um KASLR auszuhebeln. In der zweiten Phase w\u00fcrde derselbe Bug einen Buffer-Overflow verursachen. Er \u00fcberschreibt einen Callback-Pointer mit der Adresse eines Payloads, den der Angreifer bereits im Kernel-Speicher platziert hat. Wenn der Kernel diesen Pointer aufruft, f\u00fchrt das Payload einen beliebigen Shell-Befehl als Root aus. Eine verlorene Race w\u00fcrde nur diesen einzelnen Verbindungsversuch scheitern lassen, ohne das System abst\u00fcrzen zu lassen: Wiederholte Versuche w\u00e4ren also m\u00f6glich. Im von Anthropic beschriebenen Test: 48 Minuten, um die Kernel-Adresse zu stehlen, weitere 5 Minuten bis zur Befehlsausf\u00fchrung.<\/p>\n\n\n\n

Red Hat sagt, dass ein entfernter Angreifer, der einen exponierten TCP-Dienst erreicht, die Race generell ausl\u00f6sen kann. Der von Anthropic beschriebene Root-Exploit h\u00e4tte jedoch gezielt Server mit einem aktiven Multipath-TCP-Listener angegriffen. Der Beitrag von Anthropic kl\u00e4rt nicht, ob ein Server ohne MPTCP genauso ausnutzbar ist. Weder der CVE-Eintrag noch der Upstream-Fix erw\u00e4hnen MPTCP an irgendeiner Stelle. Es ist die Fachpresse, keine Prim\u00e4rquelle, die diesen Zusammenhang berichtet: Ich schreibe das deshalb mit der Skepsis, die es verdient, nicht als zu hundert Prozent gesicherte Tatsache. Anthropic hat weder den Exploit-Code ver\u00f6ffentlicht, noch die genaue verwendete Kernel-Version, noch die Konfiguration des Zielservers. Ein anderes Unternehmen, Innora, hat eine Root-Cause-Analyse ver\u00f6ffentlicht, mit einer QEMU-Reproduktionsumgebung. Es hat erkl\u00e4rt, kurzfristig keinen bewaffneten Exploit zu ver\u00f6ffentlichen. Derzeit gibt es keine Beweise f\u00fcr eine tats\u00e4chliche Ausnutzung durch Hersteller oder CERTs. Der Bug ist nicht im CISA-KEV-Katalog, laut der von CIRCL Luxemburg aktualisierten Kopie vom 28. Oktober.<\/p>\n\n\n\n

Was jetzt auf deinen Servern zu tun ist<\/h2>\n\n\n\n

Kein Hersteller hat einen offiziell sanktionierten Workaround f\u00fcr diese Schwachstelle im Linux-Kernel<\/strong> ver\u00f6ffentlicht. Red Hat sagt ausdr\u00fccklich, dass keine der bisher kursierenden Ma\u00dfnahmen seinem Standard an Deployment-Einfachheit und Stabilit\u00e4t entspricht. Die prim\u00e4re Abmilderung bleibt, den korrigierten Kernel einzuspielen und neu zu starten, sobald der Patch f\u00fcr deine Distribution verf\u00fcgbar ist. Auf Debian ist er das schon. Auf RHEL und Ubuntu noch nicht, zum Zeitpunkt, an dem ich das schreibe.<\/p>\n\n\n\n

Als Verteidigung in der Tiefe, nicht als endg\u00fcltige L\u00f6sung, ergeben einige Ma\u00dfnahmen Sinn. Pr\u00fcfen, dass net.ipv4.tcp_migrate_req<\/code> auf 0 gesetzt ist. Kontrollieren, dass keine eBPF-Programme mit BPF_SK_REUSEPORT_SELECT_OR_MIGRATE<\/code> geladen sind. Eine Filterung eingehender IPv4-Pakete mit Record-Route- oder Timestamp-Optionen erw\u00e4gen. Abst\u00fcrze \u00fcberwachen, die ip_options_build<\/code>, ip_build_and_send_pkt<\/code> oder skb_under_panic<\/code> zitieren. Ein Inventar eventuell exponierter MPTCP-Listener erstellen und vermeiden, sie ohne Grund erreichbar zu lassen. Wenn du auch Schutz gegen h\u00e4ufigere Angriffe auf Anwendungsebene verwaltest, findest du unter wie ich meine Server bis zum Patch f\u00fcr PHP2Shell abgesichert habe<\/a> denselben Ansatz. Er lautet: abmildern, was m\u00f6glich ist, w\u00e4hrend man auf den endg\u00fcltigen Fix wartet, ohne Schutz zu versprechen, den es nicht gibt.<\/p>\n\n\n\n

F\u00fcr alle, die mich fragen, ob sie sofort aktualisieren sollen: Wenn du Debian Stable nutzt, ist der korrigierte Kernel schon in den Security-Repositories. Das Update ist einfach, und das Zeitfenster der Exposition ist schon geschlossen. Wenn du andere Distributionen nutzt, gibt es heute noch keinen Patch zu installieren. Es lohnt sich, die Advisories deines Herstellers in den n\u00e4chsten Tagen genau zu verfolgen: Die Lage \u00e4ndert sich schnell.<\/p>\n\n\n\n

Quellen: The Hacker News<\/a>, Debian Security Tracker<\/a> und der Fix-Commit<\/a>. Debian, Red Hat, Ubuntu und die anderen genannten Namen sind Marken ihrer jeweiligen Eigent\u00fcmer.<\/p>\n","protected":false},"excerpt":{"rendered":"

Eine Schwachstelle im Linux-Kernel im TCP-IPv4-Code (CVE-2026-98432, CVSS 9,8) erkl\u00e4rt: was sie bedeutet, warum die Hersteller sich nicht einig sind, und wie es bei Debian, RHEL und Ubuntu mit den Patches aussieht.<\/p>\n","protected":false},"author":1,"featured_media":1400,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"wpai_generated_summary":"","footnotes":""},"categories":[363],"tags":[534,388,535,413],"class_list":["post-1406","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server-datenbanken","tag-cve","tag-debian-de","tag-linux-kernel","tag-server-sicherheit"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t