Menü schliessen
Created: November 8th 2026
Last updated: November 8th 2026
Categories: Cyber Security,  Linux
Author: Marcus Fleuti

Linux-Kernel-Lücke CVE-2026-98432: Debian- und Ubuntu-Server mit nftables schützen

Eine präparierte TCP-Verbindungsanfrage, und der Linux-Kernel liest Speicher, den er bereits freigegeben hat. CVE-2026-98432 ist ein Use-after-free im IPv4-TCP-Handshake des Linux-Kernels, bewertet mit CVSS 9,8 (kritisch). Die Lücke lässt sich über das Netzwerk auslösen, ohne Login und bevor eine Anwendung die Verbindung überhaupt sieht. Dieser Artikel erklärt, wie der Fehler funktioniert, welche Debian- und Ubuntu-Kernel gepatcht sind und wie eine einzige nftables-Regel den Angriffsweg sperrt, bis Ihr Server einen korrigierten Kernel nutzt.

Stand: 8. November 2026. Der Stand der Distributionen ändert sich schnell - prüfen Sie die verlinkten Tracker für die aktuellen Versionen.

LEXO-Maskottchen bewacht einen Server: Eine Firewall-Mauer hält Bugs mit Netzwerkpaketen ab - Angriff abgewehrt

This article is also available in English: Linux kernel CVE-2026-98432: protect Debian and Ubuntu servers with nftables

CVE-2026-98432 auf einen Blick

Eigenschaft Wert
CVE CVE-2026-98432
Komponente Linux-Kernel, Aufbau von IPv4-TCP-Verbindungen
Art Use-after-free durch eine Race Condition
Schweregrad CVSS 3.1: 9,8 kritisch - Angriff über das Netzwerk, ohne Berechtigungen, ohne Mitwirkung eines Benutzers
Betroffen Linux ab Version 4.4 mit erreichbarem IPv4-TCP-Port
Upstream behoben in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3
Korrektur Commit e3f33b0a1d89 «ipv4: free inet_opt and ireq_opt after an RCU grace period»
Veröffentlicht 15. Oktober 2026

So funktioniert der Fehler

Trifft eine TCP-Verbindungsanfrage (SYN) mit IPv4-Optionen wie Record Route oder Timestamp ein, speichert der Kernel diese Optionen bei der wartenden Verbindung, um sie im SYN-ACK zurückzusenden. Ist der Handshake abgeschlossen, übergibt der Kernel diesen Speicher an den Socket der neuen Verbindung - ohne ihn zu kopieren.

Sendet der Client dasselbe SYN erneut, kann ein zweiter CPU-Kern im selben Moment aus genau diesen Optionen ein weiteres SYN-ACK bauen. Baut der erste Kern die neue Verbindung inzwischen ab, gibt er die Optionen sofort mit kfree() frei. Der zweite Kern liest dann Speicher, der ihm nicht mehr gehört.

Grafik CVE-2026-98432: SYN mit IPv4-Optionen, zwei CPUs greifen gleichzeitig auf denselben Speicher zu, Use-after-free; Lösung kfree_rcu() und Firewall-Regel als Übergangsschutz

Die Folgen reichen von Kernel-Speicher, der ins SYN-ACK gelangt, bis zu beschädigtem Speicher und Kernel-Abstürzen. Anthropic, deren Forscher den Fehler gemeldet hat, zeigte die Ausführung von Befehlen als root aus der Ferne auf einem Server mit einem Multipath-TCP-Listener (MPTCP): rund 48 Minuten, um einen Kernel-Zeiger auszulesen, weitere fünf Minuten bis zum ersten Shell-Befehl. Ein verlorenes Rennen bricht nur den Handshake ab, der Angreifer versucht es einfach erneut. Der Fehler selbst steckt im normalen IPv4-TCP-Code - auch Server ohne MPTCP brauchen die Korrektur.

Die Korrektur gibt die Optionen mit kfree_rcu() frei, also erst dann, wenn keine andere CPU sie mehr lesen kann. IPv6-Verbindungen sind vom Hauptproblem nicht betroffen.

Schritt 1: Kernel prüfen und aktualisieren

Stellen Sie zuerst fest, welches Kernel-Paket läuft:

# Debian: die Paketversion steht nach dem Wort "Debian"
uname -v

# Ubuntu: die Paketversion steht nach dem Wort "Ubuntu"
cat /proc/version_signature

Vergleichen Sie die Version mit der Tabelle:

Distribution Kernel-Paket Behoben in Stand 8. November 2026
Debian 12 «Bookworm» linux 6.1.190-1 (DLA-4841-1) Behoben
Debian 12 «Bookworm» linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1) Behoben
Debian 13 «Trixie» linux 6.12.113-1 (DSA-6568-1) Behoben
Ubuntu 22.04 LTS linux 5.15.0-203.213 Korrektur vorbereitet, noch nicht veröffentlicht
Ubuntu 22.04 LTS (HWE) linux-hwe-6.8 6.8.0-149.149~22.04.1 Korrektur vorbereitet, noch nicht veröffentlicht
Ubuntu 24.04 LTS linux 6.8.0-149.149 Korrektur vorbereitet, noch nicht veröffentlicht
Ubuntu 24.04 LTS (HWE) linux-hwe-6.17 - Noch keine Korrektur
Ubuntu 26.04 LTS linux 7.0.0-43.43 Korrektur vorbereitet, noch nicht veröffentlicht
Ubuntu 26.10 linux 7.3.0-10.10 Behoben

Cloud-Kernel wie linux-aws, linux-azure oder linux-gcp haben eigene Versionen - siehe Ubuntu-CVE-Seite und Debian Security Tracker. Installieren Sie die Updates und starten Sie den Server neu:

sudo apt update
sudo apt full-upgrade
sudo reboot

Prüfen Sie die Version nach dem Neustart erneut. Ein neuer Kernel wirkt erst nach einem Neustart; unter Ubuntu zeigt die Datei /var/run/reboot-required, dass noch ein Neustart aussteht.

Schritt 2: IPv4-Optionen mit nftables sperren

Solange kein korrigierter Kernel läuft - unter Ubuntu LTS ist das derzeit der Fall -, schliesst eine Firewall-Regel den Angriffsweg. Der Fehler lässt sich nur mit Paketen auslösen, die IPv4-Optionen tragen, und normaler Internet-Verkehr nutzt diese praktisch nie. Die Regel verwirft deshalb jedes eingehende IPv4-Paket mit Options-Header (Header-Länge IHL > 5). Einzige Ausnahme ist IGMP, denn IGMPv2 und IGMPv3 brauchen für Multicast die Router-Alert-Option.

Diese Regel setzen wir auf unseren eigenen Servern ein:

# /etc/nftables.d/ipv4-options.nft
# Verwirft jedes eingehende IPv4-Paket mit Options-Header (IHL > 5),
# ausser IGMP (IGMPv2/v3 brauchen die Router-Alert-Option).
# CVE-2026-98432: ein SYN mit IPv4-Optionen löst ein Use-after-free aus.
# prerouting erfasst alle Interfaces inkl. lo und docker0.
# Priorität raw - 10 (= -310): vor Dockers raw PREROUTING (-300) und conntrack.
table inet ipv4-options
delete table inet ipv4-options
table inet ipv4-options {
    counter dropped {
    }

    chain prerouting {
        type filter hook prerouting priority raw - 10; policy accept;
        ip hdrlength > 5 ip protocol != igmp limit rate 1/minute log prefix "nft-ipv4-options: "
        ip hdrlength > 5 ip protocol != igmp counter name "dropped" drop
    }
}

Die ersten beiden Zeilen machen die Datei mehrfach ladbar: Die Tabelle wird angelegt, falls sie fehlt, gelöscht und dann neu definiert. Andere Firewall-Regeln - ufw, Docker oder eigene Tabellen - bleiben unberührt. Die Log-Zeile schreibt höchstens eine Meldung pro Minute, der benannte Zähler summiert alle verworfenen Pakete.

Regel aktivieren

sudo apt install nftables                          # nur falls nft fehlt
sudo install -d /etc/nftables.d
sudo nano /etc/nftables.d/ipv4-options.nft         # Regel einfügen
sudo nft -c -f /etc/nftables.d/ipv4-options.nft    # nur Syntax prüfen
sudo nft -f /etc/nftables.d/ipv4-options.nft       # aktivieren

Halten Sie beim Aktivieren eine zweite SSH-Sitzung offen und testen Sie ein neues Login - normale Verbindungen müssen weiter funktionieren.

Regel nach einem Neustart behalten

Ihr Server Vorgehen
Firewall wird in /etc/nftables.conf verwaltet (systemctl is-enabled nftables zeigt enabled) Am Ende von /etc/nftables.conf die Zeile include "/etc/nftables.d/ipv4-options.nft" ergänzen.
ufw, Docker oder kein aktiver nftables.service Die Datei mit einer kleinen systemd-Unit laden (unten). Sie legt die Tabelle beim Start an und löscht keine anderen Regeln.
sudo tee /etc/systemd/system/nft-ipv4-options.service >/dev/null <<'EOF'
[Unit]
Description=Drop IPv4 packets with options (CVE-2026-98432)
DefaultDependencies=no
Wants=network-pre.target
Before=network-pre.target shutdown.target
After=nftables.service
Conflicts=shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/nftables.d/ipv4-options.nft

[Install]
WantedBy=sysinit.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable nft-ipv4-options.service

Wirkung prüfen

# Anzahl verworfener Pakete
sudo nft list counter inet ipv4-options dropped

# Log-Einträge (höchstens einer pro Minute)
sudo journalctl -k -g nft-ipv4-options

Alternative: iptables

Wer nft nicht einsetzen kann, erreicht dasselbe mit dem u32-Match. Er liest das IHL-Feld aus dem ersten Byte des IPv4-Headers; Werte von 6 bis 15 bedeuten, dass Optionen vorhanden sind:

sudo iptables -t raw -I PREROUTING ! -p igmp -m u32 --u32 "0>>24&0xF=6:15" -j DROP

# Zähler prüfen
sudo iptables -t raw -L PREROUTING -v -n

Diese Regel ist nach einem Neustart weg. Für eine dauerhafte Lösung nehmen Sie die nftables-Variante oben - auf aktuellen Debian- und Ubuntu-Versionen läuft iptables ohnehin auf nftables.

Schritt 3: MPTCP abschalten, wenn Sie es nicht brauchen

Der veröffentlichte Exploit nutzt einen Multipath-TCP-Listener. In Go geschriebene Programme öffnen unter Linux seit Go 1.24 standardmässig MPTCP-Listener (Hinweis auf oss-security). Brauchen Sie MPTCP nicht, schalten Sie es ab:

sysctl net.mptcp.enabled                 # 1 = eingeschaltet

echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/90-disable-mptcp.conf
sudo sysctl -w net.mptcp.enabled=0

sudo ss -lnMp                            # noch offene MPTCP-Listener

Der Schalter verhindert nur neue MPTCP-Sockets. Starten Sie die Dienste neu, die noch in der Liste erscheinen.

Grenzen des Übergangsschutzes

  • Keine Korrektur: Die Firewall-Regel sperrt den bekannten Angriffsweg, den Fehler beseitigt aber erst das Kernel-Update. Installieren Sie es, sobald Ihre Distribution es ausliefert.
  • Container: Die Regel schützt den Host und die Container, deren Verkehr über ihn läuft - bei Docker der Standard. Verkehr zwischen Containern auf demselben Host kann sie umgehen.
  • CIPSO/NetLabel: Netze mit CIPSO-Sicherheitslabels übertragen diese in IPv4-Optionen - setzen Sie die Regel dort nicht ein.
  • IPv6: Das Hauptproblem betrifft IPv6 nicht, eine eigene Regel ist nicht nötig.
  • Dauerhaft behalten? IPv4-Optionen kommen im normalen Verkehr praktisch nie vor. Wir behalten die Regel dauerhaft, auch nach dem Kernel-Update.

Zusammenfassung

Massnahme Wirkung Wann
Kernel-Update und Neustart Beseitigt den Fehler Debian: jetzt. Ubuntu LTS: sobald das Update erscheint
nftables-Regel Sperrt den Angriffsweg (IPv4-Optionen) Sofort, ohne Neustart
MPTCP abschalten Entfernt die Voraussetzung des veröffentlichten Exploits Wenn MPTCP nicht gebraucht wird

So sind wir bei LEXO vorgegangen

Wir haben alle unsere Linux-Server aktualisiert, die obige Regel auf jedem Server ausgerollt und überwachen Zähler und Logs rund um die Uhr. Kunden mit unserem Hosting und Monitoring mussten nichts unternehmen. Möchten Sie das auch für Ihre Server, melden Sie sich bei uns.

Quellen