Mittels KI ist gerade eine neue Schwachstelle CVE-2026-31431 (Copy Fail) in Linux aufgedeckt worden. Diese Schwachstelle erlaubt Angreifern faktisch in allen seit 2017 veröffentlichten Linux-Distributionen Root-Rechte zu erlangen. Allerdings muss der Angreifer auf dem Linux-System ein Benutzerkonto haben. Eine Mitigation bis zur Bereitstellung von Distributions-Updates ist wohl möglich.
Schwachstelle CVE-2026-31431 im Linux-Kernel
Ich bin bereits vor einigen Stunden über nachfolgenden Tweet auf die Copy Fail Schwachstelle (CVE-2026-31431) gestoßen (die bereits im März 2026 entdeckt, aber erst zum 29. April 2026 bekannt wurde), komme aber erst jetzt dazu, das Thema aufzubereiten.
Es ist eine als Copy Fail bezeichnete Schwachstelle im Linux-Kernel, die in der Schnittstelle des kryptografischen Algorithmus algif_aead steckt. Entdeckt wurde die Schwachstelle wohl per AI. theori-io hat in diesem GitHub-Beitrag die Linux-Distributionen aufgelistet, die er getestet hat und als angreifbar betrachtet. Die technische Beschreibung bzw. Offenlegung findet sich in diesem Blog-Beitrag vom 29. April 2026.
In der Routine algif_aead gibt es eine fehlerhafte "In-Place-Operation", bei der die Zuordnungen der Quell- und Zieldaten voneinander abweichen. Dies könnte während kryptografischer Vorgänge zu unerwartetem Verhalten oder Problemen mit der Datenintegrität führen und möglicherweise die Zuverlässigkeit der verschlüsselten Kommunikation beeinträchtigen. Redhat hat bereits am 22. April 2026 in diesem Artikel Details zur Schwachstelle zusammen getragen, am 30. April 2026 gab es wohl eine Aktualisierung.
Benutzer können Root-Rechte erlangen
Ein Angreifer benötigt lediglich ein normales Benutzerkonto auf dem Rechner (es ist also nichts remote angreifbar. Von seinem lokalen Benutzerkonto kann er ein portables Python-Skript ausführen. Dieses weist den Kernel an, bestimmte Verschlüsselungen durchzuführen. Dabei nutzt das Script den Implementierungsfehler aus und schreibt 4 Bytes in den "Page Cache"-Speicherbereich (die Hochgeschwindigkeitskopie von Dateien im RAM unter Linux).
Diese 4 Bytes können auf jedes Programm abzielen, dem das System vertraut, wie beispielsweise /usr/bin/su, die Abkürzung, um Root-Rechte zu erlangen. Sobald jemand dieses Programm das nächste Mal ausführt, gewährt es dem Angreifer Root-Zugriff. Bei kernel.org hat man die Schwachstelle mit dem CVSS-Score von 7.8 eingestuft.
Noch keine Distro-Updates, aber Schutz möglich
In diesem Blog-Beitrag mit der technischen Beschreibung des Problems wird die Anwendung dieses Patches vom 31. März 2026 als Fix beschrieben. Dieser deaktiviert die "In-Place-Operation", so dass das Problem nicht mehr auftreten kann.
Wenn ich es richtig sehe, gibt es bei den meisten Linux-Distributionen noch keinen Patch für die Schwachstelle. Bei lokal betriebenen Linux-Systemen mit nur einem Nutzer dürfte das auch nicht so das Problem sein. Problematischer wird es aber bei Linux-Systemen, die als Terminal-Server, für shared Hosting, Container etc. viele Nutzer haben. Hier könnten die Nutzer Root-Rechte erlangen.
Tomas Jakobs hat hier im Diskussionsbereich des Blogs in einem Kommentar auf seinen Blog-Beitrag zum Thema verwiesen. Die von ihm angewandte Schutzmöglichkeit vor der Schwachstelle besteht schlicht darin, algif_aead zu deaktivieren bzw. zu löschen. Ist auch in diesem Blog-Post des Entdeckers so beschrieben. Dort heißt es: "For immediate mitigation, block AF_ALG socket creation via seccomp or blacklist the algif_aead< module". Dazu lässt sich nachfolgender Befehl zum Blocken verwenden:
echo"install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf rmmod algif_aead 2>/dev/null
Redhat hat in diesem Artikel aufgelistet, welche seiner Distributionen betroffen sind. Von OpenWall gibt es diese und diese Zusammenfassung zum Sachverhalt. Die NIST-Beschreibung zu CVE-2026-31431 verlinkt alle relevanten Dokumente zu Copy Fail.
MVP: 2013 – 2016
Ziemlich cooles PoC, was halt wieder zeigt eine multi-user cloud taugt nichts. Habe das mal auf meinen eigenen servern getestet. Funktioniert prächtig! Eigener bare metal server auf dem man selbst der Herr ist und gut. Leider hat mein Distro noch nicht den Kernel mit patch gepushed.
Edit:
6.18.23 manuell eingespielt, sollte auch schon ab 6.18.22 gefixt sein
Zusatz #1: Wie von Bolko im Diskussionsforum angemerkt, kann ein initramfs nicht schaden.
Zusatz #2: "On the Edge" Distris wie Arch oder Debian sid (Forky) sind gepatcht, der Rest muss auf ein Update noch warten.
Von daher finde ich den Zeitpunkt der Veröffentlichung recht suboptimal. Man hätte ja zumindest warten können, bis überall die Patches drin sind.
Man hätte aber den Bug auch einfach in den letzten 9 Jahre in dem für Jeden öffentlich lesbaren Quellcode finden können.
Eine race condition geht selten aus dem Quellcode hervor.
Aber Du willst sowieso nur trollen.
DIe aktuelle Lücke ist keine Race Condition:
"Most Linux LPEs need a race window or a kernel-specific offset.
Copy Fail is a straight-line logic flaw — it needs neither."
*ttps://copy.fail/
Offener Quellcode den jeder prüfen kann aber scheinbar nicht macht *lol*
"Noch keine Distro-Updates, aber Schutz möglich"
Bei Arch Linux wurde das System bereits mit Kernel 6.19.12 aktualisiert:
https://security.archlinux.org/CVE-2026-31431
Aktuell ist 7.0.2 im Einsatz.
Arch Linux hat jetzt Linux 7.0.3 veröffentlicht.
Seit ca. 2017 tippen wir beim su root immer das Passwort ein, dabei wäre das mit dem richtigen „Tool" gar nicht nötig gewesen. Wie viele Tippbewegungen wären uns da erspart geblieben. [/Ironie off]
Debian scheint aktuell noch keine stable releases gefixt zu haben:
https://security-tracker.debian.org/tracker/CVE-2026-31431
Ist nicht schlimm, der Bug ist ja seit 9 Jahren durch den Quellcode ja öffentlich bekannt, also wenn das jemand hätte ausnutzen wollen, um sich das sudo-Passwort zu ersparen, hätte er das jederzeit tun können.
Auf jeden Fall ist der PoC in meine Scriptsammlung gewandert. Ein unbestimmtes Gefühl sagt mir, in den nächsten Jahren werde ich auf Systeme stoßen, die nicht gepatched wurden und wo ein root Zugriff von Nutzen sein könnte ;-)
Der Befehl zum Blocken (rmmod) funktioniert nicht bei (unvollständige Liste):
RHEL,
CentOS (und Centos-basierte Nachfolger),
RockyLinux,
AlmaLinux,
denn dort ist algif_aead nicht als Kernel-Modul, sondern direkt in den Kernel reinkompiliert.
*ttps://www.reddit.com/r/sysadmin/comments/1szajkx/comment/oj25c4a/
*ttps://www.reddit.com/r/sysadmin/comments/1szajkx/comment/oj391gs/
In diesem Fall muss man es in GRUB blacklisten.
Wenn man allerdings dieses Modul löscht oder blacklistet, dann gibt es Nebenwirkungen:
Dieses cryptographische Interface wird zum Beispiel von LUKS benutzt, um das root-Systemvolume zu entschlüsseln.
*ttps://www.reddit.com/r/sysadmin/comments/1szajkx/comment/oj2xqr5/
Scheint was RHEL spezifisches zu sein. Ich kann nur für Debian (und alike) Distris sprechen. Dort gibt es mit der Mitigation bislang keine Probleme mit LUKS und/oder anderen Anwendungen.
Der User dort berichtet von Problemen, nachdem er die fest eingebaute Funktion in ein Modul ausgelagert und den kernel neu kompiliert hat. Wahrscheinlich hat da etwas beim mkinitrd nicht wie erwartet funktioniert.
Ansonsten würde LUKS ja fest einkompilierte und als Modul zur Verfügung stehende Funktionen komplett anders behandeln. Kann ich mir irgendwie nicht vorstellen.
Aber der Bootvorgang ist komplex und Initialisierung in falscher Reihenfolge sowie Timing-Probleme könnten da auch eine Rolle spielen.
Jedenfalls ist so eine Umstellung von intern nach Modul in diesem Fall wohl kein Selbstläufer.
Tumbleweed ist schon seit einigen Tagen abgesichert
https://www.suse.com/c/suse-responds-to-the-copy-fail-vulnerability/
Debian Trixi hat den Kernel 6.12.85-1als fix erhalten.
Ubuntu hat auf 6.8.0.111 aktualisiert. Ich gehe davon aus das ist der Fix. Die Ubuntu Seite ist immer noch wegen dem DDoS Angriff down.
Derweil stehen bei Microsoft im Entra-ID mal wieder alle Türen offen. Hab gerade mit etwas Verspätung einen Blick auf CVE-2026-35431 (saubere 10,0) geworfen. Es gibt doch echt nichts, was es nicht gibt…