CVE-2026-98432: TCP-Schwachstelle im Linux-Kernel — was sie bedeutet und was Sie auf Ihrem VPS oder dedizierten Server tun sollten
Sicherheit

CVE-2026-98432: TCP-Schwachstelle im Linux-Kernel — was sie bedeutet und was Sie auf Ihrem VPS oder dedizierten Server tun sollten

29 Oct 20269 min read

Eine Lücke im Linux-Kernel kann es einem entfernten Angreifer theoretisch ermöglichen, einen Server während des TCP-Handshakes zum Absturz zu bringen. Wir erklären, wer betroffen ist, welche Distributionen zum 29. Oktober 2026 bereits einen Patch haben und mit welchen konkreten Schritten Sie Ihren VPS oder dedizierten Server schützen.

Zum 29. Oktober 2026 ist die Linux-Kernel-Schwachstelle CVE-2026-98432 in den offiziellen Stable-Zweigen und in Debian behoben, aber Ubuntu, Red Hat, AlmaLinux, Rocky und SUSE 15 haben noch keinen korrigierten Kernel veröffentlicht. Zum Zeitpunkt der Veröffentlichung ist kein öffentlicher Exploit bekannt. Wenn Sie bei Fusiora einen Linux-VPS oder einen dedizierten Linux-Server haben, verwalten Sie den Kernel selbst: Dieser Artikel erklärt, was passiert ist und welche Schritte Sie unternehmen sollten.

9.8CVSS des CNA (SUSE: 8.1; Red Hat: 5.9, vorläufig)
4.4+Betroffene Kernel ab
Keiner bekanntÖffentlicher Exploit zum 29. Okt.

Was ist passiert? Einfach erklärt

Wenn jemand eine TCP-Verbindung zu Ihrem Server aufbaut, speichert der Kernel vorübergehend einige Informationen aus dem ersten Paket (dem SYN). Enthält dieses Paket IPv4-Optionen (optionale Felder im IP-Header wie Record Route oder Timestamp, die normaler Datenverkehr fast nie verwendet), kann der Kernel diesen Speicher freigeben, während ein anderer Teil des Systems ihn noch benutzt. Man spricht von einem Use-after-free.

In der Praxis ist das wahrscheinlichste Ergebnis, dass der Server abstürzt und neu startet (Denial of Service). Die offiziellen Quellen sind sich über den Schweregrad uneinig: Der CVE-Eintrag nennt außerdem eine mögliche Offenlegung von Kernel-Speicherinhalten an den Angreifer sowie Speicherkorruption, während Red Hat einen Absturz für am wahrscheinlichsten hält und angibt, dass keine Auswirkung auf Vertraulichkeit oder Integrität nachgewiesen wurde.

Technische Details in Kürze

  • Korrektur: Commit e3f33b0a1d89 „ipv4: free inet_opt and ireq_opt after an RCU grace period“ (Eric Dumazet, 1. Oktober 2026), enthalten in Linux 7.3. Er ersetzt zwei kfree()-Aufrufe durch kfree_rcu() in net/ipv4/af_inet.c und net/ipv4/tcp_ipv4.c.
  • Ursache: tcp_v4_syn_recv_sock() übergibt die IP-Optionen der Anfrage an den Child-Socket, ohne sie zu kopieren. Trifft gleichzeitig ein wiederholt gesendetes SYN ein, kann eine andere CPU gerade ein SYN-ACK mit diesen Optionen senden, während der Child-Socket zerstört wird und sie freigibt.
  • Zweite Variante: nur bei aktivierter Migration von TCP-Anfragen (net.ipv4.tcp_migrate_req=1, standardmäßig 0, oder ein reuseport-BPF-Programm, das Anfragen migriert).
  • Angriffsvektor: entfernt und ohne Authentifizierung, während des Handshakes, bevor die Anwendung beteiligt ist. Voraussetzung sind ein TCP-Dienst, der auf IPv4 lauscht, ein SYN mit IP-Optionen und eine gewonnene Race Condition. Der CNA stuft die Komplexität als niedrig ein, Red Hat und SUSE als hoch.
  • IPv6: von der Hauptlücke nicht betroffen. IPv6 muss nicht deaktiviert werden.

Wer ist betroffen?

  • Linux-VPS: Jeder VPS bootet seinen eigenen Kernel, den Sie über das Betriebssystem installieren und aktualisieren. Läuft auf Ihrem VPS ein verwundbarer Kernel, müssen Sie ihn aktualisieren und neu starten.
  • Dedizierte Linux-Server: ebenso. Sie haben vollen Root-Zugriff und der Kernel liegt in Ihrer Verantwortung.
  • Container (Docker, LXC, Podman) auf Ihrem Server: Sie teilen sich den Kernel des Hosts und sind daher geschützt, sobald der Kernel dieses Servers aktualisiert ist.
  • Nicht betroffen: Windows Server und FreeBSD, da sie nicht den Linux-Kernel verwenden.

Wichtig. Dieser Artikel behandelt das Betriebssystem, das Sie selbst verwalten. Wenn Sie Fragen zu einem anderen Teil Ihres Dienstes haben, eröffnen Sie ein Ticket und wir melden uns bei Ihnen.

Patch-Stand zum 29. Oktober 2026

Offizielle Kernel (kernel.org). Diese Versionen oder jede spätere Version desselben Zweigs enthalten die Korrektur bereits:

Zweig 5.105.10.272 oder neuer
Zweig 5.155.15.223 oder neuer
Zweig 6.16.1.190 oder neuer
Zweig 6.66.6.159 oder neuer
Zweig 6.126.12.113 oder neuer
Zweig 6.186.18.56 oder neuer
Zweig 7.27.2.10 oder neuer
Mainline7.3

Der CVE-Eintrag nennt keinen korrigierten 4.x- oder 5.4-Zweig (beide werden offiziell nicht mehr unterstützt).

Nach Distribution. Beachten Sie, dass Distributionen ihre Kernel nach eigenem Schema nummerieren; entscheidend ist daher das jeweils korrigierte Paket:

Debian 13 trixieBehoben: linux 6.12.113-1 (DSA-6568-1)
Debian 12 bookwormBehoben: linux 6.1.190-1 (DLA-4841-1); linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1)
Ubuntu 22.04, 24.04, 26.04 und 26.10 (GA-Kernel)Verwundbar, Korrektur in Arbeit. Kein USN
Ubuntu 22.04 und 24.04 (HWE-Kernel)Verwundbar, noch keine Korrektur in Arbeit
Ubuntu 16.04, 18.04 und 20.04Verwundbar (ESM, erfordert Ubuntu Pro)
RHEL 8, 9 und 10„Fix deferred“: kein korrigierter Kernel
AlmaLinux und RockyKein Advisory mit korrigiertem Kernel
RHEL 7Laut Red Hat nicht betroffen
SUSE / openSUSE Leap 16.0Behoben: kernel-default 6.12.0-160000.40.1
SUSE 15 SP4, SP5 und SP6-LTSSAusstehend (in QA, nicht veröffentlicht)
SUSE 15 SP7 und openSUSE Leap 15.6Verwundbar, keine Korrektur veröffentlicht

Bei Distributionen, die aktuelle Kernel aus den offiziellen Zweigen ausliefern (zum Beispiel Fedora, Arch oder Alpine), vergleichen Sie Ihre Version mit der kernel.org-Tabelle. Wenn Sie Debian 10 oder 11 oder ein anderes nicht mehr unterstütztes System verwenden, rechnen Sie nicht mit einem Patch: Planen Sie den Umstieg auf eine unterstützte Version (auf einem VPS im Panel unter Manage → Rebuild; beachten Sie, dass eine Neuinstallation alle Daten löscht; bei einem dedizierten Server eröffnen Sie ein Ticket). CentOS 7 verwendet den Kernel von RHEL 7, der laut Red Hat von dieser CVE nicht betroffen ist, erhält aber keine Sicherheitsupdates mehr: Eine Migration ist trotzdem ratsam.

Schritte für Kunden

Verbinden Sie sich per SSH (Anleitung) und führen Sie die Befehle als root oder mit sudo aus.

1. Prüfen, welcher Kernel läuft

uname -r

Unter Debian steht die genaue Paketversion am Ende der Ausgabe von:

uname -v

Zum Beispiel bedeutet „Debian 6.12.113-1“ oder höher unter Debian 13, dass Sie die korrigierte Version bereits haben. Unter Ubuntu, RHEL und deren Derivaten ist die Nummer von uname -r die eigene Nummerierung der Distribution: Vergleichen Sie sie mit deren Advisory, nicht mit der kernel.org-Tabelle.

2. Vor jeder Änderung ein Backup erstellen

Wenn Ihr Tarif Snapshots umfasst, erstellen Sie vor dem Update einen. Andernfalls kopieren Sie alles, was Sie nicht verlieren dürfen, vom Server herunter. Ein Kernel-Update ist Routine, aber beim Neustart kann ein bereits bestehendes Problem zutage treten.

3. Das System aktualisieren

Debian und Ubuntu:

apt update && apt full-upgrade

Wenn Sie unter Debian 12 den 6.12-Kernel aus dem Paket linux-6.12 (DLA-4850-1) verwenden, aktualisiert full-upgrade auch diesen. So prüfen Sie die installierten Kernel-Pakete:

dpkg -l 'linux-image*'

AlmaLinux, Rocky, RHEL, Fedora, Oracle und CloudLinux:

dnf upgrade --refresh

rpm -q kernel

SUSE und openSUSE:

zypper refresh && zypper patch

Arch:

pacman -Syu

Alpine:

apk update && apk upgrade

Für Ubuntu, RHEL, AlmaLinux und Rocky gibt es zum 29. Oktober noch keinen korrigierten Kernel; für Oracle Linux (UEK-Kernel) und CloudLinux prüfen Sie das Advisory Ihres Anbieters. Es lohnt sich trotzdem, ausstehende Updates einzuspielen, und Sie sollten diesen Schritt wiederholen, sobald Ihre Distribution ihr Advisory veröffentlicht (siehe Schritt 8); wenden Sie in der Zwischenzeit die Abhilfe aus Schritt 5 an.

4. Neu starten und die neue Version prüfen

Der neue Kernel wird erst nach einem Neustart verwendet:

reboot

Sobald der Server wieder erreichbar ist, führen Sie erneut uname -r aus (und unter Debian uname -v) und vergleichen das Ergebnis mit dem korrigierten Paket Ihrer Distribution (Tabelle „Nach Distribution“) oder mit der kernel.org-Tabelle, wenn Sie einen offiziellen Kernel verwenden. Wenn der Server nach dem Neustart nicht per SSH antwortet:

  • VPS: Melden Sie sich im Panel vps.fusiora.com an und öffnen Sie die VNC-Konsole (Reiter Options → Browser VNC; wenn Sie die Schaltfläche nicht sehen, klicken Sie zuerst auf Enable VNC).
  • Dedizierter Server: Verwenden Sie die IPMI/KVM-Fernkonsole.
  • Im GRUB-Menü (unter Debian und Ubuntu unter „Advanced options“; erscheint das Menü nicht, halten Sie beim Booten Shift gedrückt oder drücken Sie Esc) können Sie den vorherigen Kernel wählen, während Sie den Fehler untersuchen.

5. Wenn Ihre Distribution noch keinen Patch hat: vorübergehende Abhilfe

Die Lücke wird nur durch IPv4-TCP-SYNs mit IP-Optionen ausgelöst, die im legitimen Datenverkehr sehr selten sind. Sie können diese Pakete mit nftables verwerfen. Die Regel lässt normale SYNs durch und betrifft weder IPv6 noch andere Protokolle. Wenn Ihr Server Datenverkehr weiterleitet (zum Beispiel als Router oder VPN-Gateway), filtert sie diese SYNs auch im Transit. Sie ersetzt den Patch nicht.

Wenn der Befehl nft fehlt, installieren Sie ihn mit apt install nftables oder dnf install nftables. Die Regel liegt in einer eigenen Tabelle, die neben ufw, firewalld und Docker existieren kann:

nft add table inet cve_2026_98432

nft add chain inet cve_2026_98432 pre '{ type filter hook prerouting priority -300; policy accept; }'

nft add rule inet cve_2026_98432 pre 'ip hdrlength > 5 tcp flags & (syn | ack) == syn counter drop'

Zur Kontrolle (der Zähler zeigt, wie viele Pakete verworfen wurden):

nft list table inet cve_2026_98432

Zum Entfernen:

nft delete table inet cve_2026_98432

Auf diese Weise hinzugefügt, übersteht die Regel keinen Neustart. Tragen Sie sie dafür nicht in /etc/nftables.conf ein und aktivieren Sie dafür nicht nftables.service: Je nach Distribution leert diese Konfiguration alle Regeln des Systems, auch die von Docker oder ufw. Wenn die Regel Neustarts überdauern soll, speichern Sie sie in einer eigenen Datei, /etc/cve-2026-98432.nft:

table inet cve_2026_98432 {
  chain pre {
    type filter hook prerouting priority -300; policy accept;
    ip hdrlength > 5 tcp flags & (syn | ack) == syn counter drop
  }
}

Und laden Sie sie mit einem eigenen Dienst, /etc/systemd/system/cve-2026-98432.service:

[Unit]
Description=Mitigation CVE-2026-98432

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft
ExecStop=/usr/sbin/nft delete table inet cve_2026_98432

[Install]
WantedBy=multi-user.target

Entfernen Sie zuerst die manuelle Regel, falls Sie sie hinzugefügt haben (nft delete table inet cve_2026_98432), damit sie nicht doppelt vorhanden ist. Dann:

systemctl daemon-reload && systemctl enable --now cve-2026-98432.service

Sobald Sie den korrigierten Kernel verwenden, schalten Sie sie mit systemctl disable --now cve-2026-98432.service ab.

Auf älteren Systemen ohne nftables lautet das iptables-Äquivalent:

iptables -t raw -I PREROUTING -p tcp --syn -m u32 ! --u32 "0>>22&0x3C=20" -j DROP

Wie die von Hand hinzugefügte nft-Regel übersteht auch diese keinen Neustart.

Prüfen Sie außerdem, dass die Migrationsvariante deaktiviert ist (die Ausgabe sollte 0 sein, der Standardwert):

sysctl net.ipv4.tcp_migrate_req

Meldet der Befehl, dass der Schlüssel nicht existiert, fehlt Ihrem Kernel diese Funktion und die Variante trifft nicht zu.

Filtern Sie nicht alle Pakete mit IP-Optionen: IGMP verwendet sie, und Sie würden Multicast lahmlegen. Die obige Regel ist bewusst auf TCP-SYNs beschränkt.

6. Livepatch: nur dort, wo es ihn gibt

Zum 29. Oktober 2026 haben wir weder bei Canonical noch bei Red Hat oder SUSE einen Livepatch für diese CVE gefunden. SUSE hat für 16.0 einen korrigierten Kernel veröffentlicht (6.12.0-160000.40.1), der einen Neustart erfordert. Ohne Livepatch besteht die Lösung darin, den Kernel zu aktualisieren und neu zu starten.

7. Prüfen, was Sie ins Internet öffnen

Die Lücke setzt einen TCP-Dienst voraus, der auf IPv4 lauscht. Jetzt ist ein guter Zeitpunkt, in Ihrer Firewall (ufw oder firewalld) nicht benötigte Ports zu schließen und Administrationsports auf Ihre eigenen IPs zu beschränken. Unsere Anleitung Ihren ersten VPS einrichten beschreibt die grundlegende Firewall-Konfiguration.

8. Advisories verfolgen und bei Bedarf Hilfe anfordern

Verfolgen Sie die CVE-Seite Ihrer Distribution (Links unten) und wiederholen Sie die Schritte 3 und 4, sobald der korrigierte Kernel erscheint. Wenn Sie Fragen haben oder nach dem Update etwas nicht startet, eröffnen Sie ein Ticket mit Ihrem Dienst und der Ausgabe von uname -r.

Häufige Fragen

Aktualisiert Fusiora den Kernel auf meinem VPS oder dedizierten Server?

Nein, es sei denn, Sie haben einen Managed-Service gebucht; in diesem Fall wenden Sie sich an den Support. Bei einem Standard-VPS oder dedizierten Server haben Sie vollen Root-Zugriff und verwalten das Betriebssystem selbst, einschließlich des Kernels. Wenn Sie Hilfe bei den Schritten möchten, eröffnen Sie ein Ticket.

Reicht es, die Pakete zu aktualisieren?

Nein. Bis zum Neustart läuft weiterhin der alte Kernel. Prüfen Sie mit uname -r, dass die neue Version aktiv ist.

Muss ich IPv6 deaktivieren?

Nein. IPv6 ist von der Hauptlücke nicht betroffen.

Kann die nftables-Regel etwas kaputt machen?

Sie verwirft nur IPv4-TCP-SYNs mit IP-Optionen, die im legitimen Datenverkehr sehr selten sind. IPv6 und andere Protokolle bleiben unberührt, und ein einziger Befehl entfernt sie.

Ist mein Windows Server betroffen?

Nein. Es handelt sich um eine Schwachstelle im Linux-Kernel.

Wird die Lücke bereits ausgenutzt?

Zum Zeitpunkt der Veröffentlichung ist kein öffentlicher Exploit bekannt, und die CVE steht nicht im KEV-Katalog der CISA. Wir aktualisieren diesen Artikel, falls sich das ändert.


Quellen

  • CVE.org: offizieller Eintrag des Linux-CNA, veröffentlicht am 2026-10-15 und aktualisiert am 2026-10-24
  • NVD: CVE-Eintrag mit der Bewertung des CNA (geprüft am 2026-10-29)
  • Ubuntu: Status je Release, Priorität High (aktualisiert am 2026-10-28)
  • Debian Security Tracker: korrigierte Pakete, DSA-6568-1, DLA-4841-1 und DLA-4850-1 (geprüft am 2026-10-29)
  • Red Hat: Einstufung Moderate und Status „Fix deferred“ (geprüft am 2026-10-29)
  • SUSE: Status je Produkt (geprüft am 2026-10-29)
  • Linux-Korrektur-Commit: „ipv4: free inet_opt and ireq_opt after an RCU grace period“ (2026-10-01)
  • kernel.org: aktuelle Stable-Versionen (geprüft am 2026-10-29)
  • CISA KEV: Katalog ausgenutzter Schwachstellen, ohne diese CVE (geprüft am 2026-10-29)

War dieser Artikel hilfreich?

Sei der Erste, der bewertet