CVE-2026-31431: Kritische Linux-Kernel-Lücke jetzt patchen

Eine kritische Lücke im Linux-Kernel (CVE-2026-31431) erlaubt es einem unprivilegierten Benutzer, Root-Rechte zu erlangen oder aus einem Container auszubrechen. Praktisch alle Linux-Distributionen seit 2017 sind betroffen, ein funktionsfähiger Exploit ist öffentlich. Wer Linux-Server betreibt, sollte jetzt patchen oder zumindest den Workaround anwenden.

Worum es geht

Die Schwachstelle steckt im Crypto-API des Kernels, konkret im Modul algif_aead. Das Modul stellt authentifizierte Verschlüsselung über AF_ALG-Sockets bereit: Ein Userspace-Prozess öffnet so einen Socket, wählt den AEAD-Modus authencesn und schiebt mit splice() Daten hinein. Genau in dieser Kette schreibt der Kernel durch einen Programmierfehler vier Bytes an die falsche Stelle im Page-Cache. Diese vier Bytes reichen, um den Kernel-Zustand so zu kippen, dass ein unprivilegierter Prozess Root erlangt oder ein Container die Host-Isolation überwindet. Es braucht keine Race-Condition, kein Erraten von Kernel-Adressen und kein exotisches Speicher-Layout: der Exploit ist ein gerader Programmpfad, deshalb zuverlässig und schnell. Veröffentlicht am 29. März 2026 durch Xint Code unter copy.fail.

Bestätigt getestet sind RHEL 10.1, Ubuntu 24.04 LTS, Amazon Linux 2023 und SUSE 16. Debian, Fedora, Rocky Linux, AlmaLinux, Arch und Oracle Linux verhalten sich laut Forscher identisch. Wir haben den Exploit zusätzlich auf Rocky Linux 9 und 10 nachgestellt: privilege escalation und container escape funktionieren wie beschrieben.

Bin ich betroffen?

Schnelltest auf einem Linux-Host:

$ lsmod | grep algif_aead
$ sudo lsof 2>/dev/null | grep AF_ALG
$ ss -xa | grep -i alg

Liefert eines davon Output, ist das Modul gerade aktiv. Achtung: algif_aead wird auch on-demand geladen, sobald ein Userspace-Prozess AF_ALG öffnet. Eine leere lsmod-Ausgabe ist also keine Entwarnung. Im Zweifel: Sperre setzen.

Sofortmassnahme: Modul sperren

Solange der Distributor noch keinen Kernel-Patch ausgeliefert hat:

$ echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
$ sudo rmmod algif_aead 2>/dev/null || true

Validierung:

$ lsmod | grep algif_aead              # leer
$ sudo modprobe -v algif_aead          # liefert "install /bin/false" und Fehler

Auf den meisten Systemen ist die Abschaltung folgenlos. dm-crypt/LUKS, kTLS, IPsec, OpenSSL/GnuTLS/NSS in Standard-Builds, SSH und das Kernel-Keyring-Crypto nutzen AF_ALG nicht (Details auf copy.fail). Nur Userspace, der explizit auf AF_ALG setzt (zum Beispiel OpenSSL mit afalg-Engine oder eigene Crypto-Offload-Pfade), sollte vorher gegengeprüft werden.

Container-Hosts

Der Bug erlaubt einen Ausbruch aus dem Container. Da Kernel-Module zum Host gehören und Container den Kernel teilen, gehört die Sperre zwingend auf den Host. Eine reine Container-seccomp- oder SELinux-/AppArmor-Policy reicht nicht. Sobald algif_aead auf dem Host gesperrt ist, ist es für alle laufenden Container gesperrt.

Patch einspielen

Sobald der Kernel-Update verfügbar ist:

# RHEL / Rocky / Alma / Fedora
$ sudo dnf check-update kernel

# Debian / Ubuntu
$ sudo apt update && apt list --upgradable | grep linux-image

Update einspielen, neu starten, danach kann die Modul-Sperre zurückgenommen werden, falls gewünscht:

$ sudo rm /etc/modprobe.d/disable-algif.conf
$ sudo systemctl reboot

Stand 30. April 2026 sind die Patches nicht bei allen Distributoren bereits ausgeliefert. Distros-Tracker und eigene Mirror-Server im Auge behalten.

Du benötigst Hilfe?

Du betreibst Linux-Server und bist unsicher, ob ihr betroffen seid oder wie ihr den Workaround sauber ausrollt? Melde dich.

Kontakt