Copy Fail – CVE-2026-31431

 (copy.fail)
9 Punkte von GN⁺ 2026-04-30 | 5 Kommentare | Auf WhatsApp teilen
  • Container-Escape-Privilege-Escalation-Schwachstelle, mit der sich seit 2017 auf allen Linux-Distributionen root-Rechte erlangen lassen
  • Nutzt einen einfachen Logikfehler im Kryptomodul des Linux-Kernels (authencesn) aus und kann ohne kompliziertes Timing (Race Condition) oder distributionsspezifische Anpassungen an Kernel-Versionen mit einem einzigen 732-Byte-Python-Skript ausgeführt werden
  • Das Kernprinzip besteht darin, den In-Memory-Cache (Page Cache) zu manipulieren, auf den Linux beim Ausführen von Dateien zugreift. Dazu werden AF_ALG (Kernel-Kryptografie-Sockets) und splice() (Systemaufruf zum Kopieren von Daten) kombiniert, um 4 Byte in die Cache-Kopie eines setuid-Binaries zu überschreiben
    • Die eigentliche Datei auf der Festplatte bleibt unverändert, sodass es sich um einen Stealth-Angriff handelt, der in forensischen Disk-Images keine Spuren hinterlässt
    • Nach einem Neustart oder wenn der Speicher freigegeben wird, kehrt der Cache zum Original zurück; eine nachträgliche Erkennung mit klassischen Dateiintegritätsprüfungen ist daher schwierig
  • Da der Page Cache hostweit gemeinsam genutzt wird, kann in Kubernetes-Umgebungen ein einzelner Pod diese Schwachstelle nutzen, den Host-Node übernehmen und als Container Escape auch in Container anderer Tenants eindringen
  • Direkt verifiziert unter Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 und SUSE 16; funktioniert sofort mit nur einem unprivilegierten lokalen Benutzerkonto, ohne Netzwerkzugriff oder Kernel-Debugging-Funktionen
  • Bestehende Linux-LPE-Schwachstellen arbeiten pro Versuch oft nur mit 30–80 % Erfolgsquote und nur in bestimmten Kernel-Bereichen; Copy Fail dagegen betrifft mit 100 % Erfolgsquote pro Einzelversuch 9 Jahre lang (2017–2026) alle Distributionen
  • Im Unterschied zu verwandten Angriffen auf die Manipulation des Page Cache wie Dirty Pipe (Missbrauch von Pipe-Buffer-Flags) und Dirty Cow (erfordert Timing-Rennen) ist sie durch fehlende Race Condition, keine distributionsabhängigen Offsets und nicht notwendige Neukompilierung deutlich einfacher und mächtiger
  • Am dringendsten betroffen: Multi-Tenant-Linux-Hosts, Kubernetes-/Container-Cluster, CI-Runner (GitHub Actions Self-Hosting, GitLab Runner usw.), Cloud-SaaS mit Ausführung von Benutzercode — also jede Umgebung, in der nicht vertrauenswürdiger Code auf einem gemeinsam genutzten Kernel läuft
  • Höchste Priorität hat ein Kernel-Patch (Mainline-Commit a664bf3d603d) — dabei wird die 2017 eingeführte In-Place-Optimierung des Kryptomoduls rückgängig gemacht, damit Page-Cache-Seiten nicht mehr zu den Schreibzielen kryptografischer Operationen gehören
  • Als vorübergehende Maßnahme vor dem Patch kann das Modul algif_aead deaktiviert werden; allgemeine Kryptofunktionen wie dm-crypt/LUKS, kTLS, IPsec und SSH sind nicht betroffen
  • Für Umgebungen mit nicht vertrauenswürdigen Workloads wie Container, Sandboxes oder CI-Runner wird unabhängig vom Patch-Status empfohlen, per seccomp die Erzeugung von AF_ALG-Sockets zu blockieren
  • Taeyang Lee von Xint leitete die frühe Erkenntnis ab, dass „die Struktur, in der splice() Page-Cache-Seiten an das Kryptografie-Subsystem übergibt, eine unerforschte Bug-Klasse ist“, und Xint Code fand den Fehler als Beispiel für KI-gestützte Schwachstellenerkennung, indem es das crypto/-Subsystem des Kernels in etwa einer Stunde automatisch scannte

Verwandte Beiträge

5 Kommentare

 
popopo 2026-05-04

Bei Rocky Linux scheint es noch keinen Patch zu geben.

RHEL

AlmaLinux

Rocky Linux

Wenn Sie Rocky Linux verwenden und nicht neu starten können, ist das Blockieren mit bpftool aus https://github.com/wgnet/wg.copyfail.patch wirksam.
 
popopo 2026-05-04

https://kb.ciq.com/article/rocky-linux/rl-cve-2026-31431-mitigation

Es gibt zwar einen Patch, aber er wird nur über das Repository des Abo-Dienstes bereitgestellt. Die CE-Version erhält keinen Patch. (9.7, 10.1 geprüft)
 
popopo 2026-05-10

Der Patch ist am 2026-05-05 erschienen.

Am 2026-05-10 gibt es eine neue Sicherheitsoption.
https://forums.rockylinux.org/t/…

sudo dnf --enablerepo=security update

Wenn man das Sicherheits-Repository hinzufügt, scheinen Sicherheitsmaßnahmen unabhängig von der Übernahme der RHEL-Quellen möglich zu sein.
 
sukso96100 2026-05-02

Für Ubuntu-Nutzer gibt es einen Leitfaden mit Maßnahmen, der als Referenz hilfreich sein dürfte.

https://discourse.ubuntu.com/t/…
 
GN⁺ 2026-04-30
Hacker-News-Kommentare

  • Aus der Perspektive von jemandem, der sich mit Linux-Kernel-Crypto-Code beschäftigt, sind die regelmäßig auftauchenden AF_ALG-Exploits wirklich frustrierend
    AF_ALG ist vor langer Zeit ohne ausreichendes Review in den Kernel gekommen, die Struktur ist viel zu komplex und sie öffnet nicht privilegierten Userspace-Programmen eine riesige Angriffsfläche
    Außerdem ist es fast überflüssig. Im Userspace gibt es bereits eigene Kryptographie-Implementierungen, und der Kernel-Crypto-Code war ursprünglich für interne Kernel-Anwendungsfälle wie dm-crypt gedacht
    Auch das authencesn in diesem Exploit ist im Grunde ein Implementierungsdetail innerhalb von IPsec, und es als allgemeine Userspace-API für Ver- und Entschlüsselung offenzulegen, war aus meiner Sicht von Anfang an ein Fehler
    Wenn man Linux-Kernel-Konfigurationen verwaltet, würde ich dringend empfehlen, alle Optionen CONFIG_CRYPTO_USER_API_* zu deaktivieren
    Schon das allein hätte nicht nur diesen Bug, sondern auch viele frühere und künftige AF_ALG-Bugs unbrauchbar für eine Ausnutzung gemacht
    Falls dadurch Userspace-Programme kaputtgehen, sollte man ihnen lieber beim Umstieg auf Userspace-Krypto-Code helfen, und teils ist genau das ohnehin schon passiert
    AF_ALG hatte von Anfang an ohnehin nicht viele sinnvolle Anwendungsfälle außer Exploits
    Solche Userspace-APIs waren früher vielleicht noch halbwegs vertretbar, aber mit syzbot und LLM-gestützter Bug-Erkennung wird das heute kaum noch tragfähig sein

    • Da ich nicht wusste, was AF_ALG ist, habe ich nachgesehen und bin auf https://www.chronox.de/libkcapi/html/ch01s02.html gestoßen; dort werden durchaus Gründe für seine Existenz genannt
      Genannt werden unter anderem, dass sich Hardware-Beschleuniger, die nur im Kernel-Modus zugänglich sind, so im Userspace nutzen lassen, dass Schlüssel an den Kernel übergeben werden können, ohne lange im Speicher der Anwendung zu verbleiben, und dass sich in speicherknappen Umgebungen wie Embedded-Systemen der Footprint gegenüber Userspace-Krypto-Bibliotheken verringern lässt
      Ob das eine ausreichend gute Rechtfertigung ist, kann ich nicht beurteilen, aber zumindest gibt es überhaupt eine Begründung
    • Ich frage mich, wie das überhaupt in den Kernel gekommen ist
      Linus gilt als ziemlich wählerisch dabei, was in den Kernel aufgenommen wird, deshalb wäre die Geschichte hinter so einer API interessant
    • AF_ALG ist ein Linux-Socket-Interface, das die Kernel-Crypto-API über Dateideskriptoren verfügbar macht
      Damit lassen sich Hashing und Verschlüsselung über gewöhnliche read(2)-/write(2)-Aufrufe behandeln
    • Am meisten würde mich interessieren, welche Software kaputtgeht, wenn man diese Kernel-Option deaktiviert

  • Beim Veröffentlichungsprozess scheint es etwas Verwirrung gegeben zu haben
    Die Anbieter scheinen diese Schwachstelle nicht besonders ernst zu nehmen, weshalb sie bei mehreren Distributionen noch ungepatcht geblieben ist
    Auf https://access.redhat.com/security/cve/cve-2026-31431 stand „Moderate severity“ und „Fix deferred“, und die Tracking-Seiten von Debian, Ubuntu und SUSE sahen ähnlich aus

    • Seit dem Zeitpunkt, an dem der Patch in den Kernel aufgenommen wurde, war das Thema für Angreifer oder Beobachter faktisch schon seit Wochen bekannt
      Nur hat Upstream das nicht klar als Schwachstelle kommuniziert, und Linus sowie Greg legen im Kernel konzeptionell ohnehin nicht besonders viel Wert auf solche Klassifizierungen
    • Dass Distributionen das als mittleres Risiko sehen, liegt wohl daran, dass keine Remote Code Execution möglich ist, sondern lokaler Zugriff erforderlich ist
      Trotzdem ermöglicht es lokal eine Privilegieneskalation auf root, daher wirkt eine hohe Priorität im Allgemeinen angemessen
      https://ubuntu.com/security/cves/about#priority
    • Red Hat hat das inzwischen auf Important severity und Affected geändert
    • Nach Ubuntus eigenen Richtlinien müsste das eigentlich high priority sein, die tatsächliche Kennzeichnung als medium wirkt daher inkonsistent

  • Schade ist, dass im Text nicht direkt steht, welche Kernel-Versionen verwundbar sind und in welchen Versionen der Fix enthalten ist
    Gerade weil es sich hier um ein builtin-Modul handelt, das sich nicht einfach mit rmmod entfernen lässt
    Beim Nachsehen, ob Kernel 6.19.14 in Fedora 44 verwundbar ist, bin ich auf den Beitrag in der Mailingliste linux-cve-announce gestoßen: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u
    Dort steht, dass der Fehler jeweils in 6.18.22, 6.19.12 und 7.0 durch die entsprechenden Commits behoben wurde, was als Referenz hilfreich ist

  • Wenn man prüfen möchte, ob wie empfohlen das Kernel-Modul algif_aead per modprobe-Konfiguration blockiert wurde, muss man nicht den ganzen verschleierten Shell-Code ausführen
    Mit ein paar Zeilen Python wie unten lässt sich deutlich lesbarer prüfen, ob das Modul tatsächlich geladen wird
    python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
    Wenn die Abschwächung korrekt greift, sollte auch modprobe algif_aead mit einem Fehler fehlschlagen

  • Hoffentlich lässt niemand auf betroffenen Betriebssystemen vollautonome KI-Agenten mit normalen Benutzerrechten laufen
    In Kombination mit Zero-Day-Prompt-Injection könnte das ziemlich katastrophal sein

    • Mein Agent läuft ohnehin schon als root, also sehe ich das Problem nicht
    • Zum Glück haben wir es nicht zum Industriestandard gemacht, Dinge per curl | sh zu installieren

  • LPE bedeutet local privilege escalation
    Es gibt im Security-Bereich einfach zu viele Abkürzungen, und auch wenn man es aus dem Kontext erschließen konnte, hätte ich es anfangs trotzdem gern ausgeschrieben gesehen

    • LPE ist innerhalb der Security-Community eine ziemlich geläufige Abkürzung, daher würde ich das Weglassen der Erklärung nicht als besonders gravierend ansehen
      Für einen Text mit breiterem Publikum wäre eine explizite Definition aber sicher sinnvoll
      Zumal der ganze Artikel ohnehin wie KI-generiert wirkt
    • Für Texte an ein breites Publikum gehört es eigentlich zum Grundhandwerk, Abkürzungen zuerst auszuschreiben, aber LLMs halten sich an solche Richtlinien oft nicht besonders gut

  • Das ist ein bisschen komisch
    Auf der Seite steht, es laufe auf RHEL 14.3, aber so eine Version existiert gar nicht
    RHEL ist derzeit bei 10.x, ich dachte schon, ich sei in einer TARDIS gelandet

    • 14.3 scheint keine RHEL-Version zu sein, sondern eher aus der GCC-Versionsangabe von Red Hat zu stammen
      So etwas wie gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2) kommt vor, und in den Beispielen unten sieht man ähnliche Spuren
      https://github.com/anthropics/claude-code/issues/40741
      https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/software-requirements-red-hat-enterprise-linux-10-64-bit.html
    • In derselben Zeile steht auch 6.12.0-124.45.1.el10_1, und das ist eindeutig ein RHEL-10-Kernel
      Solche Tippfehler sind eher typisch menschlich
      Lange Zahlenfolgen aus Copy-and-paste sind korrekt, aber die einfachen Zahlen tippt man von Hand und vertut sich dabei
    • Tut mir leid, das wird noch korrigiert
      Um das Problem zu erklären, mussten Informationen eilig zusammengetragen werden, und ja, es hatte auch einen Marketing-Aspekt
      Dadurch sind ein paar kleine Fehler hineingeraten, danke fürs Hinweisen
    • Ja, in dem Moment, in dem ich „Direkt verifizierte Distributionen: RHEL 14.3“ gelesen habe, wirkte die Release-Seite auf mich zumindest wie AI Slop
      https://access.redhat.com/articles/red-hat-enterprise-linux-release-dates
      Und als ich unten auf der Seite noch „Talk to our security experts“ gesehen habe, fragte ich mich schon, ob dieser Security-Experte vielleicht Claude heißt

  • Unter RHEL 9/10 ist algif_aead kein Modul, sondern builtin und lässt sich daher nicht entladen
    Deshalb wurde als zweitbeste Lösung eine Methode gefunden, AF_ALG über systemd zu blockieren, was für jeden exponierten Dienst ein eigenes Drop-in erfordert
    Es gibt auch ein Ansible-Playbook, das die meist entscheidenden Fälle sshd und user@ abdeckt
    https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464da

    • Unter RHEL 9/10 konnte man auch initcall_blacklist=algif_aead_init als Kernel-Boot-Parameter setzen und neu starten
      Danach funktionierte der Exploit nicht mehr
    • Ich hatte eine ähnliche Richtung im Kopf, aber es pro Dienst zu blockieren fühlt sich nach Whac-A-Mole an
      Ich frage mich, was dann mit anderen Ausführungspfaden wie cronjob oder slurmjob ist, und statt es in jeden einzelnen Dienst einzubauen, wäre es gut, wenn es auf systemd-Ebene eine Möglichkeit gäbe, es an alle Prozesse vererbt durchzusetzen

  • Dieser Exploit scheint SUID-Binärdateien auszutauschen, damit sie mit PID 0 ausgeführt werden
    Gleichzeitig behauptet die Seite aber auch Ausbrüche aus Kubernetes-/Container-Clustern sowie CI-Runnern und Build-Farmen, ohne dass ich eine eigentliche Erklärung dafür sehe, wie Container- oder insbesondere User-Namespace-Escapes funktionieren sollen
    In rootless Podman getestet, konnte ich den Container erwartungsgemäß nicht verlassen
    Außerdem wurde behauptet, dass „alle Linux-Distributionen seit 2017 rootbar“ seien, tatsächlich getestet wurden aber nur vier, und auf Alpine funktionierte es nicht

    • Laut Seite sollen bald genauere Erklärungen folgen, daher kommen die zusätzlichen Schritte oder Korrekturen vermutlich in Teil 2
      Angekündigt ist: "Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."
    • Mit dieser Schwachstelle lassen sich Speicherbytes überschreiben, die zu lesbaren Dateien gehören, daher kann man sich grundsätzlich schon vorstellen, wie Ausbrüche in verschiedenen Umgebungen möglich sein könnten
    • Die Behauptung alle Distributionen seit 2017 beruht offenbar darauf, dass die Schwachstelle in einem Commit aus der zweiten Hälfte von 2017 eingeführt wurde
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee3
      Ob eine Ausnutzung tatsächlich möglich ist, dürfte aber davon abhängen, ob es sich um aktuelle Major-Releases oder um Maintenance-Kernel älterer Zweige handelt
    • Dieser Artikel untergräbt seine eigene Glaubwürdigkeit ziemlich stark
      Trotzdem habe ich den PoC selbst auf einer 24.04-Instanz ausgeführt, und die Schwachstelle scheint real und ernst genug zu sein
      Die Zahl der betroffenen Distributionen wirkt aber deutlich kleiner als behauptet und weit entfernt von „allen Distributionen seit 2017“
      Wenn ich das richtig lese, ist Ubuntu beispielsweise sogar in 16.04 EOL leicht betroffen, während die eigentliche Hauptwirkung eher bei kürzlich ausgerollten Vendor-Kerneln wie linux-gcp und linux-oracle-6.7 aus dem 6.17-Zweig zu liegen scheint
    • Selbst wenn man innerhalb eines rootless Containers nur bis zur tatsächlichen UID 0 kommt, kann man von dort aus den nächsten Ausbruchsschritt eventuell noch schaffen
      Dafür braucht es aber weitere Schritte, und auch bei Alpine kann es sein, dass die zugrunde liegende Schwachstelle vorhanden ist und nur das Skript angepasst werden muss
      Am Ende ist das kein fertiger universeller Exploit, sondern ein PoC

  • Die Seite selbst wirkt etwas vibecoded und werblich, aber die Schwachstelle ist real und die Risikoeinstufung scheint hoch zu sein
    Das erklärt, warum heute ein größeres Security-Update hereinkam, und ich sollte die Update-Priorität wohl erhöhen

    • Das ist zwar ziemlich unverhohlene Werbung, aber ich finde sie persönlich nicht schlecht
      Sie finden reale Bugs, helfen beim Patchen und leisten damit einen sinnvollen Beitrag zum OSS-Ökosystem, während sie zugleich ihre eigenen Security-Tools verkaufen
    • Diese Leute hätten wahrscheinlich auch ohne Werbung schon mehr als genug Arbeit
      Andererseits baut heute vermutlich ohnehin niemand mehr Webseiten komplett von Hand, und besonders bei Kernel-Entwicklern erscheint das noch plausibler