Linux-Kernel-Sicherheitslücke CVE-2026-98432: vorübergehende Blockierung und Kernel-Patch einspielen

CVE-2026-98432 ist eine Sicherheitslücke im Linux-Kernel, bei der Kernel-Code, der IPv4-TCP-Verbindungen annimmt, bereits freigegebenen Speicher erneut liest; das CVE-Team des Linux-Kernels hat sie als Critical eingestuft. Da sich die Lücke ohne Authentifizierung aus der Ferne angreifen lässt, haben wir einen Lightsail-Server mit AlmaLinux 9.8, Nginx und Apache auf die korrigierten Kernel-Pakete aktualisiert, neu gestartet und den Patch anschließend an der laufenden Kernel-Version geprüft.

1️⃣ Linux-Kernel-Sicherheitslücke CVE-2026-98432: Funktionsweise und Auswirkungen

Kommt eine TCP-Verbindungsanfrage (SYN) mit IPv4-Optionen an, bewahrt der Kernel eine Kopie dieser Optionen bei der wartenden Verbindung auf, um sie in seiner Antwort (SYN-ACK) zurückzuschicken. Steht die Verbindung, geht diese Kopie ohne Duplikat direkt an den Socket der neuen Verbindung über.

Schickt der Client in der Zwischenzeit das SYN erneut, kann eine andere CPU gerade ein SYN-ACK mit denselben Optionen bauen. Wird die neue Verbindung dabei geschlossen und gibt der Kernel den Speicher der Optionen sofort frei, liest der Code, der das SYN-ACK baut, bereits freigegebenen Speicher: ein Use-after-free.

Dieser Code läuft in der Phase, in der der Kernel die Verbindungsanfrage verarbeitet, noch bevor die Anwendung die Verbindung sieht. Egal welcher Dienst den Port geöffnet hat: Lauscht er über IPv4-TCP, erreicht ein Angriff ihn ohne Anmeldedaten aus der Ferne, und die Bewertung liegt nach CVSS 3.1 bei 9.8.

Die Lücke besteht seit Linux 4.4, daher sind die meisten Linux-Server betroffen. Unter den Lightsail-Blueprints nennt die AWS-Anleitung AlmaLinux 9, CentOS Stream 9, Debian, openSUSE Leap, Ubuntu sowie Amazon Linux 2 und Amazon Linux 2023. Die AlmaLinux-Ankündigung nennt 8, 9 und 10 als betroffen, und auch die Anwendungs-Blueprints von Lightsail wie WordPress und LAMP laufen auf Debian oder Ubuntu und sind damit ebenfalls betroffen.

FreeBSD und Windows Server, die keinen Linux-Kernel verwenden, sind nicht betroffen.

Auch Server mit deaktiviertem MPTCP (Multipath TCP) brauchen den Patch. Der veröffentlichte Angriff zielte auf Server mit offenem MPTCP-Listener, doch die Lücke selbst steckt im normalen IPv4-TCP-Code; daher sagt auch die AlmaLinux-Ankündigung, dass Systeme ohne MPTCP ebenfalls korrigiert werden müssen.

Der korrigierte Kernel gibt den Speicher der Optionen erst nach Ablauf einer RCU-Wartefrist (grace period) frei, sodass der Speicher erhalten bleibt, solange eine andere CPU die Optionen für ein SYN-ACK liest.

2️⃣ Linux-Kernel-Version prüfen: Ist der Kernel korrigiert?

Ob ein Patch nötig ist, hängt von der laufenden Kernel-Version ab; daher haben wir vor dem Update zuerst Distribution und Kernel-Version geprüft.

cat /etc/os-release

NAME="AlmaLinux"
VERSION="9.8 (Olive Jaguar)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.8"
PLATFORM_ID="platform:el9"
PRETTY_NAME="AlmaLinux 9.8 (Olive Jaguar)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:9::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-9"
ALMALINUX_MANTISBT_PROJECT_VERSION="9.8"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.8"
SUPPORT_END=2032-06-01

uname -r

5.14.0-687.55.1.el9_8.x86_64

nft --version

-bash: nft: command not found

Die Distribution war AlmaLinux 9.8, der laufende Kernel 5.14.0-687.55.1.el9_8. Auch der Befehl nft für die Regel zur vorübergehenden Blockierung fehlte, das Paket nftables war also nicht installiert.

rpm -q kernel

kernel-5.14.0-611.30.1.el9_7.x86_64
kernel-5.14.0-687.49.1.el9_8.x86_64
kernel-5.14.0-687.55.1.el9_8.x86_64

[rpm -q kernel] listet die installierten Kernel auf, aber bis zum Neustart läuft tatsächlich nur der eine, den [uname -r] anzeigt. Vergleiche diese Version mit der korrigierten Version in der AlmaLinux-Ankündigung.

5.14.0-687.55.1.el9_8 war niedriger als 5.14.0-687.64.1.el9_8, die korrigierte Version für AlmaLinux 9, und musste daher aktualisiert werden.

Um zu sehen, ob ein Weg für den Angriff offen war, haben wir die lauschenden IPv4-TCP-Ports und den MPTCP-Status geprüft.

ss -lnt4

State  Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*
LISTEN 0      511          0.0.0.0:443       0.0.0.0:*
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*

sysctl net.mptcp.enabled

net.mptcp.enabled = 0

ss -lnM

State Recv-Q Send-Q Local Address:Port Peer Address:Port

Die IPv4-TCP-Ports, die auf allen Adressen (0.0.0.0) lauschten, waren 80 und 443 des Webservers sowie 22 für SSH.

[net.mptcp.enabled] war 0 und es gab keine MPTCP-Sockets, also war der MPTCP-Weg des veröffentlichten Angriffs geschlossen. Die Lücke beginnt aber bei normalen IPv4-TCP-Verbindungen, deshalb braucht ein Server, der auf drei IPv4-Ports lauscht, den Patch trotzdem.

3️⃣ Linux-Kernel-Update: sieben Kernel-Pakete und ein Neustart

Vor dem Kernel-Wechsel haben wir in der Lightsail-Konsole einen manuellen Snapshot der Instanz erstellt. Lightsail hat keinen Bildschirm zur Auswahl des Boot-Kernels; startet der Server mit dem neuen Kernel nicht, stellst du ihn wieder her, indem du aus diesem Snapshot eine neue Instanz erstellst.

🔲 Lightsail-Snapshot-Simulator

🔲 Linux-Kernel-Update und Neustart prüfen

Die im Repository bereitgestellte korrigierte Kernel-Version haben wir mit einer dnf-Liste geprüft.

dnf --showduplicates list available kernel kernel-core kernel-modules kernel-modules-core kernel-tools kernel-tools-libs kernel-headers

kernel.x86_64                 5.14.0-687.64.1.el9_8   baseos
kernel-core.x86_64            5.14.0-687.64.1.el9_8   baseos
kernel-modules.x86_64         5.14.0-687.64.1.el9_8   baseos
kernel-modules-core.x86_64    5.14.0-687.64.1.el9_8   baseos
kernel-tools.x86_64           5.14.0-687.64.1.el9_8   baseos
kernel-tools-libs.x86_64      5.14.0-687.64.1.el9_8   baseos
kernel-headers.x86_64         5.14.0-687.64.1.el9_8   appstream

dnf download kernel-core-5.14.0-687.64.1.el9_8

Lädt nur die Paketdatei kernel-core in den aktuellen Ordner herunter, ohne sie zu installieren.

rpm -Kv kernel-core-5.14.0-687.64.1.el9_8.x86_64.rpm

    V4 RSA/SHA256 Signature, key ID b86b3716: OK

rpm -qp --changelog kernel-core-5.14.0-687.64.1.el9_8.x86_64.rpm | grep CVE-2026-98432

- ipv4: free inet_opt and ireq_opt after an RCU grace period (CKI Backport Bot) [RHEL-295635] {CVE-2026-98432}

Die Signatur war OK, und das Änderungsprotokoll enthielt eine Zeile mit der Korrektur für CVE-2026-98432. In den dnf-Sicherheitshinweisen (updateinfo), die wir am 3. November geprüft haben, fehlte dieses CVE noch, sodass sich dieser Kernel mit [dnf upgrade --security] nicht holen ließ.

Deshalb haben wir die sieben Kernel-Pakete mit genauer Versionsangabe installiert.

dnf install -y kernel-5.14.0-687.64.1.el9_8 kernel-core-5.14.0-687.64.1.el9_8 kernel-modules-5.14.0-687.64.1.el9_8 kernel-modules-core-5.14.0-687.64.1.el9_8 kernel-tools-5.14.0-687.64.1.el9_8 kernel-tools-libs-5.14.0-687.64.1.el9_8 kernel-headers-5.14.0-687.64.1.el9_8

================================================================================
 Package                Architecture Version                    Repository    Size
================================================================================
Installing:
 kernel                 x86_64    5.14.0-687.64.1.el9_8      baseos       1.1 M
 kernel-core            x86_64    5.14.0-687.64.1.el9_8      baseos        17 M
 kernel-modules         x86_64    5.14.0-687.64.1.el9_8      baseos        40 M
 kernel-modules-core    x86_64    5.14.0-687.64.1.el9_8      baseos        31 M
Upgrading:
 kernel-headers         x86_64    5.14.0-687.64.1.el9_8      appstream    2.6 M
 kernel-tools           x86_64    5.14.0-687.64.1.el9_8      baseos       1.3 M
 kernel-tools-libs      x86_64    5.14.0-687.64.1.el9_8      baseos       1.1 M
Removing:
 kernel                 x86_64    5.14.0-611.30.1.el9_7      @baseos        0
 kernel-core            x86_64    5.14.0-611.30.1.el9_7      @baseos       64 M
 kernel-modules         x86_64    5.14.0-611.30.1.el9_7      @baseos       33 M
 kernel-modules-core    x86_64    5.14.0-611.30.1.el9_7      @baseos       27 M

Transaction Summary
================================================================================
Install  4 Packages
Upgrade  3 Packages
Remove  4 Packages

Total download size: 94 M

Complete!

Vier neue Kernel-Pakete wurden installiert, die drei Pakete kernel-headers, kernel-tools und kernel-tools-libs aktualisiert, und sonst änderte sich kein Paket. Weil die Einstellung [installonly_limit=3] bis zu drei installierte Kernel behält, wurden die vier Pakete des ältesten Kernels 5.14.0-611.30.1.el9_7 entfernt; vom Download bis zum Abschluss dauerte es 74 Sekunden.

Der offizielle Befehl aus der AlmaLinux-Ankündigung holt die Repository-Daten neu und aktualisiert dann alle Pakete, für die es ein Update gibt.

sudo dnf clean metadata && sudo dnf upgrade

Da dabei neben dem Kernel auch andere Pakete aktualisiert werden, findest du die Schritte für ein Upgrade der gesamten Distributionsversion in Alma Linux Update: 9.4 → 9.8 in LightSail.

Der neue Kernel wird erst nach einem Neustart wirksam.

systemctl reboot

Nachdem der Server wieder hochgefahren war, haben wir nacheinander den laufenden Kernel, die installierten Kernel und den Standard-Kernel geprüft.

uname -r

5.14.0-687.64.1.el9_8.x86_64

rpm -q kernel

kernel-5.14.0-687.49.1.el9_8.x86_64
kernel-5.14.0-687.55.1.el9_8.x86_64
kernel-5.14.0-687.64.1.el9_8.x86_64

grubby --default-kernel

/boot/vmlinuz-5.14.0-687.64.1.el9_8.x86_64

Der Server war weniger als eine Minute nach dem Neustartbefehl wieder da, und sowohl der laufende Kernel als auch der Standard-Kernel für den nächsten Start wechselten auf 5.14.0-687.64.1.el9_8. Der vorherige Kernel 5.14.0-687.55.1.el9_8 ist noch vorhanden; macht der neue Kernel Probleme, kannst du den Standard-Kernel zurückstellen.

4️⃣ Vorübergehende Blockierung vor dem Neustart: nft-Regeln und ihre Grenzen

Wenn du nicht sofort neu starten kannst, lassen sich die Pakete, die die Lücke auslösen, bis zum Einspielen des korrigierten Kernels mit einer vorübergehenden Regel blockieren. Die Befehle in diesem Abschnitt haben wir nicht selbst ausgeführt; sie folgen der offiziellen Anleitung (den Ankündigungen von AlmaLinux und AWS).

Auf dem Lightsail-Server mit AlmaLinux 9.8, Nginx und Apache dauert ein Neustart nur wenige Minuten, deshalb haben wir den Kernel ohne vorübergehende Blockierung direkt aktualisiert.

Die Lücke wird nur durch TCP-Verbindungsanfragen mit IPv4-Optionen ausgelöst. Normaler Datenverkehr nutzt IPv4-Optionen kaum; wenn du nur IPv4-TCP-Pakete mit Optionen blockierst, bleiben gewöhnliche Verbindungen daher erhalten.

sudo dnf install -y nftables

Der Befehl nft steckt im Paket nftables, das zusammen mit firewalld installiert wird. Fehlt der Befehl auf deinem Server, installiere es zuerst.

sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength > 5 counter drop
    }
}
EOF

Legt eine Tabelle an, die TCP-Pakete mit einer IPv4-Headerlänge über 5, also Pakete mit IPv4-Optionen, in der Phase prerouting verwirft. AlmaLinux hat diese Regel auf 8, 9 und 10 getestet; sie lässt sich zusammen mit firewalld verwenden und kann gefahrlos mehrfach ausgeführt werden.

sudo nft list table ip cve_2026_98432

Prüft, ob die Regel aktiv ist; der Wert counter in der Ausgabe ist die Zahl der bisher verworfenen Pakete.

sudo nft delete table ip cve_2026_98432

Nach dem Neustart mit dem korrigierten Kernel löschst du die Tabelle mit diesem Befehl.

Diese Regel verschwindet beim Neustart; hast du also vor dem Einspielen des korrigierten Kernels neu gestartet, führe den Befehl zum Anlegen der Tabelle erneut aus.

Für Server mit Anwendungen, die auf IPv4-Optionen angewiesen sind, passt diese Regel nicht. Ein Beispiel sind Netzwerke mit CIPSO-Sicherheitslabels (NetLabel), die in IPv4-Optionen übertragen werden; in der Standardkonfiguration werden sie nicht verwendet.

Die Regel schützt den Host und Container, die ihren Datenverkehr über den Host erhalten (Standardmodus bei Podman und Docker). Datenverkehr zwischen Containern auf demselben Host kann diese Regel umgehen.

Unter Debian, Ubuntu und openSUSE verwendest du die einzeilige iptables-Regel aus der AWS-Anleitung. Den Kerneln von AlmaLinux 9 und CentOS Stream 9 fehlt das von dieser Regel genutzte u32-Match, daher gilt dort die nft-Regel oben.

sudo iptables -I INPUT 1 -p tcp -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

Der u32-Ausdruck liest das Feld für die IPv4-Headerlänge; ist der Wert größer als 5, trägt das Paket IPv4-Optionen. Nach dem Einspielen des korrigierten Kernels entfernst du diese Regel mit dem Befehl unten.

sudo iptables -D INPUT -p tcp -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

Ungenutzte Ports in der Lightsail-Firewall zu schließen und die übrigen auf vertrauenswürdige IP-Adressen zu beschränken, empfiehlt ebenfalls die AWS-Anleitung.

🔢 FAQ & empfohlene Inhalte

🔗 Empfohlene Artikel

Weitere CVE-Abwehr: OpenSSH OpenSSH-Sicherheitslücke CVE-2024-6387: vorübergehende Blockierung und Patch einspielen Die OpenSSH-Sicherheitslücke CVE-2024-6387 nutzt das Alarmsignal aus, das ausgelöst wird, wenn die verbindende Seite die Anmeldung nicht innerhalb von 120 Sekunden abschließt. Zusammengefasst in dieser Reihenfolge: Alarm abschalten, um die dringende Lücke zu schließen, Code per Update korrigieren und danach zurückstellen. Artikel lesen →

Kernelversion Befehle zum Prüfen der Linux-Kernel-Version und so prüfst du die Distributionsversion Unter Linux prüfst du die Kernel-Version mit dem Befehl uname. Paketverwaltung dnf-Befehl: Pakete installieren, aktualisieren, entfernen und Unterschiede zu yum Der Befehl dnf ist der Paketverwaltungsbefehl, mit dem du unter Linux der RHEL-Familie Pakete suchst, installierst, aktualisierst und entfernst. PHP-Sicherheitslücke PHP-Sicherheitslücke: PHP2Shell-Patch und PHP-Version prüfen (WordPress) Es ist eine Lücke zur Remote-Codeausführung, durch die selbst Anfragen ohne Anmeldung Code auf dem Server ausführen können; daher kommt es zuerst darauf an, die PHP-Version deiner Website zu prüfen und auf eine gepatchte Version anzuheben.

ℹ️ Affiliate-Hinweis
Die Inhalte dieser Website enthalten Affiliate-Links. Kauft ein Besucher über einen dieser Links ein Produkt oder eine Dienstleistung, erhält die Website vom Verkäufer eine Provision. Der Betrag, den der Käufer zahlt^{(bei Aktionsrabatten sinkt er ↓)}, steigt dadurch nicht. Angegebene Preise, Rabatte und Lagerbestände entsprechen dem Stand bei Erstellung und können abweichen; prüfe sie daher vor dem Kauf beim Verkäufer. Produkte werden nach eigenen Kriterien ausgewählt und bewertet, und Provisionen beeinflussen weder die Reihenfolge noch den Inhalt der Bewertungen.