Der Kernel ist installiert. Läuft er auch?
Themenstand: 03.11.2026 · Für den Blog aufbereitet am 06.11.2026. Auf Basis vorhandener Postingtexte neu ausgearbeitet.
CVE-2026-98432 betrifft den TCP-Verbindungsaufbau. Der übertragbare Punkt für den Betrieb: Ein eingespieltes Paket und ein wirksamer Fix sind nicht automatisch dasselbe.
Ein Netzwerkfehler tief unter der Anwendung
CVE-2026-98432 ist ein bestätigter Fehler in der Verarbeitung von IPv4-TCP-Verbindungen im Linux-Kernel. Ein gleichzeitig bearbeiteter Verbindungsversuch kann auf bereits freigegebene Speicherinformationen zugreifen. Diese Fehlerklasse heißt Use-after-free. Canonical beschreibt mögliche Codeausführung aus der Ferne.
Anthropic dokumentierte einen Forschungsnachweis mit einem Multipath-TCP-Listener, bei dem ein entfernter Angreifer ohne Zugangsdaten Befehle mit höchsten Rechten ausführen konnte. Das ist ein konkretes untersuchtes Szenario. Daraus wird hier keine Behauptung, jeder erreichbare Linux-Dienst lasse sich unter allen Bedingungen auf identische Weise übernehmen.
Den Patchstand pro System bestimmen
Für den Betrieb zählen Distribution, Kernelvariante und tatsächlich laufende Version. Ein allgemeiner Versionsvergleich mit dem unveränderten Upstream-Kernel kann täuschen, weil Distributionen Sicherheitskorrekturen in ihre eigenen Pakete zurückportieren. Die passende Herstellerbewertung ist deshalb Teil der Bestandsaufnahme.
Der ursprüngliche Postingstand beschrieb noch einen frühen Ubuntu-Freigabestand. Solche Angaben altern schnell. Die verlinkte Ubuntu-CVE-Seite führt den Status pro Paket und Veröffentlichung weiter. Wer jetzt Maßnahmen plant, sollte diesen aktuellen Status prüfen, statt eine damalige Aussage zum Testkanal als dauerhaft gültige Installationsanweisung zu übernehmen.
Ein engerer Angriffsweg ist kein geschlossener Fehler
Canonical weist ausdrücklich darauf hin, dass die Schwachstelle nicht auf Multipath TCP beschränkt ist. Dessen Abschaltung darf deshalb nicht als vollständige Behebung verkauft werden. Auch andere vorübergehende Filtermaßnahmen müssen anhand der Herstellerhinweise und ihrer Grenzen bewertet werden.
Mein praktischer Test würde drei Zustände auseinanderhalten: Paket verfügbar, Paket installiert, Korrektur im laufenden Kernel wirksam. Der vorgesehene Neustart gehört in das Wartungsfenster. Eine anwendbare Livepatch-Abdeckung muss für genau diesen Fehler und Kernel nachgewiesen sein; der bloße Einsatz eines Livepatch-Produkts ersetzt diesen Nachweis nicht.
Container machen den Host nicht unwichtig
Bei normalen Containern bleibt der Kernel des jeweiligen Hosts der entscheidende gemeinsame Unterbau. Ein neues Anwendungsimage allein behebt deshalb keinen Fehler im weiterlaufenden Hostkernel. Bei verwalteten Plattformen muss geklärt sein, welche Aktualisierung der Anbieter übernimmt und welche Knoten oder Instanzen der Betreiber selbst erneuern muss.
Der Takeaway von Maurizio Schmidt: Den Abschluss an einem überprüften Betriebszustand festmachen. Nach Aktualisierung und geplantem Neustart die laufende Version gegen die Herstellerfreigabe prüfen, Erreichbarkeit und Anwendungen testen und den Nachweis dokumentieren. So wird aus einem grünen Paketmanager eine nachvollziehbar geschlossene Maßnahme.