Copy Fail – CVE-2026-31431

• Ein nicht privilegierter lokaler Benutzer kann authencesn, AF_ALG und splice() verketten, um einen 4-Byte-Schreibzugriff auf den Page Cache einer lesbaren Datei zu erzeugen und damit bis zu Root-Rechten zu eskalieren
• Ohne kernel-spezifische Offsets oder Race Conditions funktioniert dies mit einem einzigen 732-Byte-Python-Skript unverändert auf mehreren Linux-Distributionen; mit demselben Exploit lässt sich eine Root-Shell erlangen
• Betroffen sind bis zur Einspielung des Patches die meisten großen Linux-Distributionen; durch das in der Standardkonfiguration aktivierte AF_ALG besteht seit 2017 bis zum Patch-Zeitpunkt eine breite Angriffsfläche
• Auf Multi-Tenant-Hosts, in Kubernetes-/Container-Clustern, CI-Runnern und Cloud-SaaS mit Ausführung von Benutzercode kann bereits ein normales Konto oder ein einzelner Pod zu Host-Root führen, daher ist vorrangiges Patchen erforderlich
• Als Gegenmaßnahme hat ein Kernel-Patch mit dem Mainline-Commit a664bf3d603d Priorität; bis dahin sind das Deaktivieren von algif_aead und das Blockieren von AF_ALG für nicht vertrauenswürdige Workloads wichtig

---

Überblick über die Schwachstelle

• Ein geradliniger Logikfehler kann über authencesn, AF_ALG und splice() zu einem 4-Byte-Schreibzugriff auf den Page Cache verknüpft werden, was eine lokale Privilegieneskalation ermöglicht
• Ohne kernel-spezifische Offsets oder Race Windows funktioniert ein einziges 732-Byte-Python-Skript auf Linux-Distributionen, die seit 2017 veröffentlicht wurden, auf die gleiche Weise
• Dieselbe Exploit-Binärdatei erlangt auf mehreren Distributionen ohne Anpassungen eine Root-Shell
• Es genügt ein nicht privilegiertes lokales Konto; weder Netzwerkzugriff noch Kernel-Debugging-Funktionen oder andere vorinstallierte Primitive sind erforderlich

Betroffener Bereich

• Die meisten großen Linux-Distributionen mit Kerneln vor dem Patch fallen in den betroffenen Bereich
• Da AF_ALG der Kernel-Krypto-API in der Standardkonfiguration praktisch auf allen Mainstream-Distributionen aktiviert ist, besteht von 2017 bis zum Patch-Zeitpunkt unmittelbare Exponierung
• Direkt verifiziert wurden Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3 und SUSE 16
• Debian, Arch, Fedora, Rocky, Alma, Oracle sowie Embedded-Derivate sind ebenfalls betroffen, wenn sie verwundbare Kernel verwenden

Umgebungen mit vorrangigem Patch-Bedarf

• Auf Multi-Tenant-Linux-Hosts teilen sich mehrere Benutzer denselben Kernel, sodass ein beliebiges Benutzerkonto unmittelbar Root werden kann
• In Kubernetes-/Container-Clustern wird der Page Cache hostweit geteilt, sodass ein einzelner Pod einen Node übernehmen und Tenant-Grenzen überschreiten kann
• Bei CI-Runnern und Build-Farmen kann nicht vertrauenswürdiger PR-Code, der mit normalen Benutzerrechten läuft, auf dem Runner Root werden
• In Cloud-SaaS mit Ausführung von Benutzercode können von Tenants hochgeladene Container oder Skripte zu Host-Root führen
• Single-Tenant-Server haben eher den Charakter einer internen LPE und können mit Web-RCE oder kompromittierten Zugangsdaten kombiniert werden
• Bei Notebooks und Workstations mit Einzelbenutzerbetrieb ist die Dringlichkeit geringer, doch lokale Codeausführung kann direkt zur Root-Eskalation führen

Öffentliches PoC und Nutzungsweise

• Das PoC ist veröffentlicht, damit Verteidiger es zur Systemvalidierung und zur Prüfung von Vendor-Patches nutzen können
• copy_fail_exp.py verwendet nur die Python-3.10+-Standardbibliotheken os, socket und zlib
• Standardziel ist /usr/bin/su; über argv[1] kann eine andere Setuid-Binärdatei übergeben werden
• Es modifiziert die Setuid-Binärdatei im Page Cache; die Änderung bleibt nach einem Neustart nicht bestehen, die erlangte Root-Shell funktioniert jedoch real
• Issue tracker

Gegenmaßnahmen

• An erster Stelle ist ein Kernel-Patch erforderlich; aktualisiert werden muss auf einen Distributions-Kernel, der den Mainline-Commit a664bf3d603d enthält
• Dieser Patch macht die 2017 eingeführte In-Place-Optimierung von algif_aead rückgängig, sodass Page-Cache-Seiten nicht in einer beschreibbaren Destination-Scatterlist landen
• Vor dem Patch wird das Deaktivieren des Moduls algif_aead empfohlen
  • echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
  • rmmod algif_aead 2>/dev/null || true
• In Containern, Sandboxes und CI-Umgebungen mit nicht vertrauenswürdigen Workloads muss unabhängig vom Patch-Status per seccomp die Erzeugung von AF_ALG-Sockets blockiert werden

Auswirkungen einer Deaktivierung

• Auf den meisten Systemen gibt es kaum messbare Auswirkungen
• dm-crypt / LUKS, kTLS, IPsec/XFRM, In-Kernel-TLS, Standard-Builds von OpenSSL/GnuTLS/NSS, SSH und Kernel-Keyring-Kryptografie sind nicht betroffen
  • Diese verwenden die Kernel-Krypto-API direkt und durchlaufen nicht den AF_ALG-Pfad
• Wenn in OpenSSL die afalg-Engine explizit aktiviert wurde, bei einigen Embedded-Krypto-Offloading-Pfaden oder bei Anwendungen, die aead-/skcipher-/hash-Sockets direkt binden, kann es Auswirkungen geben
  • Prüfen lässt sich das mit lsof | grep AF_ALG oder ss -xa
• Auch wenn AF_ALG deaktiviert wird, werden Ziele, die es ohnehin nicht aufgerufen haben, nicht langsamer; betroffene Ziele fallen auf gewöhnliche Userspace-Kryptobibliotheken zurück

Was diese Linux-LPE von typischen Fällen unterscheidet

• Anders als bei üblichen Linux-LPEs gibt es keine Race Condition, und distributionsspezifische Offsets sind ebenfalls nicht nötig
• Die Zuverlässigkeit wird zudem mit 100 % in einem einzigen Versuch angegeben; abgedeckt wird kein enger Kernel-Versionsbereich, sondern der lange Zeitraum von 2017 bis 2026
• Mit nur 732 Byte und ausschließlich Python-Standardbibliotheken gibt es weder kompilierte Payloads noch zusätzliche Abhängigkeiten
• Der Schreibpfad umgeht das VFS, und die beschädigte Seite wird nicht als dirty markiert, sodass nichts auf die Platte geschrieben wird
• Da der Page Cache hostweit geteilt wird, funktioniert dies über eine einfache LPE hinaus auch als Primitive für Container-Escape

Funktionsweise und Erkennungsmerkmale

• Ein nicht privilegierter lokaler Benutzer kann kontrollierbare 4 Byte in den Page Cache lesbarer Dateien eines Linux-Systems schreiben und dies zum Erlangen von Root-Rechten nutzen
• Ziel ist nicht die Datei auf der Platte, sondern der Page Cache im Speicher; wird die gecachte Kopie von /usr/bin/su verändert, entspricht dies aus Sicht von execve einer Änderung der Binärdatei selbst
• Da es keine Änderung auf der Platte gibt, wird inotify nicht ausgelöst; nach Neustart oder Cache-Eviction wird die Originaldatei erneut geladen
• Übliche Hash-Werkzeuge wie sha256sum, AIDE oder Tripwire lesen den Page Cache über read(), daher können sie solange die Beschädigung im Cache verbleibt von der Referenz-Hashsumme abweichen
• Wird der Cache verdrängt oder das System neu gestartet, stimmt der Hash wieder mit dem Original überein, und auch in forensischen Disk-Images bleibt nur die unveränderte Datei zurück
• Im IMA-Appraisal-Enforcing-Mode kann bei aktiviertem Every-Read-Measurement die beschädigte Binärdatei beim execve erkannt werden, bevor sie ausgeführt wird

Unterschied zu anderen Schwachstellen

• Ähnlich wie Dirty Pipe kann aus nicht privilegiertem Userspace der Page Cache beschädigt und ohne Änderungen auf der Platte in Setuid-Binärdateien geschrieben werden, um Root zu erlangen
• Der Mechanismus ist jedoch anders: Dirty Pipe missbrauchte Pipe-Buffer-Flags, Copy Fail missbraucht einen AEAD-Scratch-Write, der über verkettete Scatterlist-Grenzen hinausgeht
• Dirty Pipe erforderte Kernel 5.8 oder neuer mit einem bestimmten Patch-Level, Copy Fail deckt dagegen das Zeitfenster von 2017 bis 2026 ab
• Anders als bei Dirty Cow muss kein TOCTOU-basiertes COW-Race gewonnen werden; es sind keine mehrfachen Versuche nötig, und das System wird nicht instabil gemacht

Weitere Details

• /usr/bin/su ist nicht zwingend; jede für Benutzer lesbare Setuid-Root-Binärdatei kommt infrage, etwa passwd, chsh, chfn, mount, sudo oder pkexec
• Es handelt sich nicht um eine Remote-Schwachstelle; zunächst ist lokale Codeausführung mit normalen Benutzerrechten erforderlich
• Wenn eine Web-RCE in einem nicht privilegierten Service-Konto landet, kann sie in Kombination mit einem SSH-Foothold oder einem bösartigen PR in einem CI-Runner bis zu Root führen
• Der Patch macht die In-Place-Optimierung von algif_aead rückgängig und trennt req->src und req->dst wieder in separate Scatterlists
• Page-Cache-Seiten verbleiben nur noch in der schreibgeschützten Quelle, während als beschreibbares Ziel nur noch Benutzerpuffer übrig bleiben

Offenlegungszeitplan und weitere Materialien

• 2026-03-23 Meldung an das Linux-Kernel-Sicherheitsteam
• 2026-03-24 erste Bestätigung
• 2026-03-25 Patch wurde vorgeschlagen und begutachtet
• 2026-04-01 Patch wurde in den Mainline-Zweig committed
• 2026-04-22 CVE-2026-31431 wurde vergeben
• 2026-04-29 Veröffentlichung auf https://copy.fail/
• Technische Analyse im Xint-Blog
  • Enthält Root Cause, Scatterlist-Diagramme, die Historie 2011→2015→2017 und einen Exploit-Walkthrough
  • Part 2 zu Kubernetes-Container-Escape soll später veröffentlicht werden

Informationen zu Xint Code

• Gefunden wurde es AI-assisted; der Ausgangspunkt war menschliche Forschung zu der Beobachtung, dass splice() Page-Cache-Seiten an das Crypto-Subsystem übergibt und dass die Herkunft von Seiten in Scatterlists eine weniger untersuchte Bug-Klasse sein könnte
• Anschließend erweiterte Xint Code das Audit des gesamten Linux-Subsystems crypto/ auf ungefähr eine Stunde, und der schwerwiegendste Fund darunter war Copy Fail
• Xint Code
  • Xint-Blog-Write-up
  • Im selben Scan wurden weitere Hochrisiko-Bugs entdeckt, die sich noch im Prozess der koordinierten Offenlegung befinden