CVE-2026-31431 — Copy Fail

Lokale Privilegieneskalation in der kryptografischen Vorlage authencesn des Linux-Kernels über AF_ALG + splice().
Offengelegt am 29. April 2026 von Theori (Xint Code).

Übersicht

Zusammenfassung der Schwachstelle

Ein Logikfehler im AEAD-Wrapper authencesn des Kernels ermöglicht es einem lokalen Benutzer ohne Privilegien, einen deterministischen, kontrollierten 4-Byte-Schreibvorgang in den Page Cache einer beliebigen lesbaren Datei auf dem System durchzuführen — einschließlich setuid-Binaries wie /usr/bin/su.

Die Ursache ist eine In-Place-Verarbeitungsoptimierung aus dem Jahr 2017, die Page-Cache-Seiten in eine beschreibbare Scatterlist legte. Der Algorithmus authencesn schreibt während der Neuordnung der Extended Sequence Number 4 Bytes Scratch-Daten außerhalb seines vorgesehenen Ausgabebereichs. Aufgrund der durch die Optimierung eingeführten Scatterlist-Struktur landen diese 4 Bytes im Page Cache einer Datei, die über splice() eingespeist wird — wobei Dateiberechtigungen vollständig umgangen werden.

Keine Race Condition. Keine Wiederholungsversuche. Kein Absturzrisiko. Deterministisch auf allen getesteten Distributionen.

Vergleich mit früheren Arbeiten

Betroffene Versionen

Verwundbar: Linux-Kernel 4.14 bis 6.18.21 und 6.19.x vor 6.19.12.

Alle großen Distributionen, die Kernel in diesem Bereich ausliefern, sind betroffen, darunter:

Nicht betroffen: Ubuntu 26.04 (Resolute) und später.

Gegenmaßnahmen

Option 1 — Patch (Empfohlen)

Aktualisieren Sie auf einen Kernel, der den Mainline-Commit a664bf3d603d enthält, der die In-Place-Optimierung von 2017 zurücknimmt.

# Ubuntu / Debian
sudo apt update && sudo apt upgrade -y && sudo reboot

# RHEL / AlmaLinux / Amazon Linux
sudo dnf clean metadata && sudo dnf upgrade && sudo reboot

# SUSE
sudo zypper refresh && sudo zypper update kernel-default && sudo reboot

Option 2 — algif_aead deaktivieren (Temporär)

Wenn ein sofortiges Patchen nicht möglich ist, deaktivieren Sie das verwundbare Modul, um die Angriffsfläche zu schließen.

Hinweis für RHEL-Familie: algif_aead ist auf RHEL/AlmaLinux/CentOS fest in den Kernel eingebaut (CONFIG_CRYPTO_USER_API_AEAD=y). Der modprobe.d-Workaround funktioniert auf diesen Systemen nicht. Verwenden Sie stattdessen die initcall_blacklist-Methode.

Debian/Ubuntu (Modul ist ladbar):

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

RHEL-Familie (fest eingebaut — Neustart erforderlich):

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

Nach dem Neustart bestätigen:

grep initcall_blacklist /proc/cmdline

Was dieser Workaround beeinflusst

Option 3 — seccomp (Defense-in-Depth)

Für nicht vertrauenswürdige Workloads — Container, CI-Runner, Sandbox-Umgebungen — blockieren Sie die Erstellung von AF_ALG-Sockets über eine seccomp-Richtlinie, unabhängig vom Patch-Status. Dies begrenzt die Angriffsfläche auch auf verwundbaren Kerneln.

Erkennung

Prüfen Sie, ob algif_aead derzeit geladen oder in Verwendung ist:

# Prüfen, ob das Modul geladen ist
lsmod | grep algif_aead

# Prüfen, ob ein Prozess einen AF_ALG-Socket offen hat
lsof | grep AF_ALG
ss -xa | grep alg

Laufzeit-Erkennungssignaturen sind in Sysdig Secure verfügbar (Regel: AF_ALG Page Cache Poisoning Leading to Privilege Escalation).

Referenzen

Offenlegungszeitplan

Autor

xD The Watcher — Red Teamer, Ethical Hacker & AI-Sicherheitsforscher
GitHub: @xd20111
Blog: yourhacker

Hinweise

Dieses Repository dokumentiert die Schwachstelle zu Forschungs- und Verteidigungszwecken. Für den maßgeblichen technischen Writeup und den offiziellen PoC verweisen wir auf die oben verlinkte Offenlegung von Theori.

Wenn Ihr Bedrohungsmodell Shared-Kernel-Multi-Tenancy umfasst — Container auf einem gemeinsamen Host, CI-Runner, Build-Farmen — ist die Isolationsgrenze bis zum Patch deutlich schwächer. Hardware- oder VM-basierte Isolation ist die richtige Antwort, nicht Namespace-Grenzen.