xd20111/cve-2026-31431Dokumentation und Analyse einer lokalen Privilege-Escalation-Schwachstelle in der authencesn-Vorlage des Linux-Kernels über AF_ALG und splice(), einschließlich betroffener Versionen, Erkennung und Gegenmaßnahmen.
Lokale Privilegieneskalation in der kryptografischen Vorlage
authencesndes Linux-Kernels überAF_ALG+splice().
Offengelegt am 29. April 2026 von Theori (Xint Code).
| Feld | Detail |
|---|---|
| CVE | CVE-2026-31431 |
| Spitzname | Copy Fail |
| CVSS | 7.8 HOCH |
| Typ | Lokale Privilegieneskalation (LPE) |
| Eingeführt | Linux-Kernel 4.14 (2017, Commit 72548b093ee3) |
| Behoben | Mainline-Commit a664bf3d603d |
| Erfordert | Lokalen Shell-Zugriff ohne Privilegien |
| Remote-Vektor | Keiner — nur lokal |
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.
| Dirty Cow (2016) | Dirty Pipe (2022) | Copy Fail (2026) | |
|---|---|---|---|
| Race Condition erforderlich | Ja | Teilweise | Nein |
| Versionsspezifisch | Ja | Ja | Nein |
| Zuverlässigkeit | Unbeständig | Mittel | Deterministisch |
| Distro-Abdeckung | Begrenzt | Begrenzt | Alle seit 2017 |
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:
| Distro | Getestete Version |
|---|---|
| Ubuntu 24.04 LTS | 6.17.0-1007-aws |
| Amazon Linux 2023 | 6.18.8-9.213.amzn2023 |
| RHEL 10.1 | 6.12.0-124.45.1.el10_1 |
| SUSE 16 | 6.12.0-160000.9-default |
Nicht betroffen: Ubuntu 26.04 (Resolute) und später.
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
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_aeadist auf RHEL/AlmaLinux/CentOS fest in den Kernel eingebaut (CONFIG_CRYPTO_USER_API_AEAD=y). Dermodprobe.d-Workaround funktioniert auf diesen Systemen nicht. Verwenden Sie stattdessen dieinitcall_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
| Komponente | Auswirkung |
|---|---|
| dm-crypt / LUKS | ✅ Nicht betroffen |
| SSH | ✅ Nicht betroffen |
| IPsec / XFRM | ✅ Nicht betroffen |
| kTLS / In-Kernel-TLS | ✅ Nicht betroffen |
| OpenSSL / GnuTLS / NSS (Standard-Builds) | ✅ Nicht betroffen |
OpenSSL mit explizit aktivierter afalg-Engine | ⚠️ Fallback auf Userspace-Krypto |
Anwendungen, die aead/skcipher/hash AF_ALG-Sockets direkt binden | ⚠️ Werden brechen — prüfen mit lsof | grep AF_ALG |
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.
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).
| Ressource | Link |
|---|---|
| NVD-Eintrag | https://nvd.nist.gov/vuln/detail/CVE-2026-31431 |
| Theori Vollständiger Writeup | https://xint.io/blog/copy-fail-linux-distributions |
| Copy-Fail-Website | https://copy.fail |
| CERT-EU Advisory | https://cert.europa.eu/publications/security-advisories/2026-005/ |
| Sysdig-Analyse | https://sysdig.com/blog/cve-2026-31431-copy-fail-linux-kernel-flaw-lets-local-users-gain-root-in-seconds |
| The-Register-Berichterstattung | https://theregister.com/2026/04/30/linux_cryptographic_code_flaw/ |
| AlmaLinux-Patchhinweise | https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/ |
| CloudLinux KernelCare | https://blog.cloudlinux.com/cve-2026-31431-copy-fail-kernel-update |
| Datum | Ereignis |
|---|---|
| 2017 | Regression eingeführt über Commit 72548b093ee3 |
| Anfang April 2026 | Upstream-Fix zusammengeführt (Commit a664bf3d603d) |
| 29. April 2026 | Öffentliche Offenlegung durch Theori / Xint Code |
| 30. April 2026 | Distributions-Patches beginnen ausgeliefert zu werden |
| 1. Mai 2026 | AlmaLinux gepatchte Kernel in Produktions-Repos |
xD The Watcher — Red Teamer, Ethical Hacker & AI-Sicherheitsforscher
GitHub: @xd20111
Blog: yourhacker
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.