Vier Root-Access Exploits veröffentlicht
https://www.openwall.com/lists/oss-security/2026/09/18/3
Aus der Mail:
"Emailing here now that the embargo agreed upon with linux-distros@ has
expired.
Flagging four local root vulnerabilities in the Linux kernel, originally
reported to security@kernel.org and the relevant maintainers in
mid-July:"
Es sind wieder sehr spezielle Mechanismen, die genutzt werden. Ich vermute, gefunden/getestet wurden die ebenfalls mit KI. Aber: die jetzt veröffentlichten Exploit-Code (PoCs) ermöglichen halt jedem User mit Shell-Zugang u.U. recht einfach Root-Access, deshalb (mal wieder...) dieser Post hier.
Tl;dr: Die Anfälligkeiten für die Exploits wurden kernel.org im Juli gemeldet. Die Archlinux Kernel sind - soweit ich das testen konnte, siehe unten - bereits gefixt. D.h. die offiziellen Kernel-Sourcecodes für die von kernel.org bereitgestellten Versionen/Varianten sind entsprechend geändert worden. Somit auch unsere Archlinux Kernel.
Speziell interessant dürfte das sein für Admins von Fedora/Ubuntu(Debian?) Server-Varianten, es schadet nichts sich die o.a. Mail (und ggf. den PoC-Code/READMEs mal anzuschauen).
Übersicht
| Kernel | Version | CVE-2026-80844 | CVE-2026-81000 | CVE-2026-68121 | CVE-2026-74469 |
| linux | 7.2.6.arch2-1 | FIX ✅ | FIX ✅ | ??? | ??? |
| linux-lts | 6.18.52-1 | FIX ✅ | FIX ✅ | ??? | ??? |
| linux-zen | 7.2.6.zen2-1 | FIX ✅ | FIX ✅ | ??? | ??? |
| linux-hardened | 7.2.5.hardened1-1 | FIX ✅ | FIX ✅ | ??? | ??? |
| linux-rt | 7.2.6.rt3.arch1-1 | FIX ✅ | FIX ✅ | ??? | ??? |
| linux-rt-lts | 6.18.52.rt6.arch1-1 | FIX ✅ | FIX ✅ | ??? | ??? |
| linux-mainline¹ | 7.3rc3-1 | FIX ✅ | FIX ✅ | ??? | ??? |
¹ Der linux-mainline ist kein offizieller Archlinux Kernel.
??? - konnte ich nicht testen, s.u.
Infos
Es sind alles Exploits, die einem unprivilegiertem User Root-Acces (eine Shell) ermöglichen. Entweder durch Verändern der /etc/pam.d/su (CVE-2026-80844, CVE-2026-81000) oder durch Inline Code-Kompilieren und Manipulation von (Kernel)-Speicher.
Es sind alles sehr spezielle Exploit-PoCs(ProofOfConzept), die auf spezielle Distributionen(Fedora/Ubuntu Server-Varianten) und Hardware-Gegebenheiten ausgerichtet sind. Die, die ich testen konnte mußte ich den Code meist schon modifizieren, um Prüfungen auf o.a. Distris zu umgehen. Sie anderen beiden (die mit ???) kann ich wohl in einer VM nicht testen (es sind z.B. bestimmte CPU-Features nötig die es in einer VM nicht gibt). Und ich teste nur in (Qemu) virtuellen Maschinen, weiter gehen meine Ambitionen, Möglichkeiten nicht.
Spezielle Dinge zu den Einzelnen:
- DirtyAH6 (CVE-2026-80844)
Das PoC modifiziert /etc/pam.d/su (über den Mechanismus des Exploits wohl nicht auf pam beschränkt!) und ermöglicht so über su eine paßwortlose Root-Shell. Ein älterer linux-next Kernel 7.1.0-rc7-next-20260612-1 war ebenfalls nicht anfällig.
- TUNderflow (CVE-2026-81000)
Wie oben wird durch PoC ebenfalls /etc/pam.d/su manipuliert. Hier war der alte linux-next 7.1.0-rc7-next-20260612-1 anfällig, ich bekam also eine root shell. Die Archlinux-Kernels sind nicht betroffen.
Ein schneller Check für beide Exploit-PoCs ist:
pacman -Qkk util-linux
Es sollten (speziell bei pam) keine veränderten Dateien oder Checksum-Fehler angezeigt werden. Außer ihr habt z.B. an den /etc/pam.d/* Konfigurations-Files selbst Änderungen gemacht. Aber wie schon gesagt, nur diese Test-PoCs nehmen pam, es könnten wohl auch andere Manipulationen über den Mechanismus erfolgen.
- PPPoEject (CVE-2026-68121)
Hier bin ich mir nicht sicher, ob (nach Verändern des PoC-Scripts damit es startet) die Ausgabe etwas "sinnvolles" signalisiert:
[gerhard@client1 PPPoEject]$ python pppoeject_root_repro.py
Target: Fedora 7.2.6-arch2-1
CPU assignment: 4 available; sender 0; reclaim CPUs 1; FUSE 2; release 3; orchestrator 3; 4 high-order workers.
*** BUILDING REQUIRED HELPERS ***
*** DISCOVERING KERNEL LAYOUT ***
Reproducer stopped: kernel-layout helper stopped with status 1: vendor=AMD cpu=0 pti=not-detected
kernel text signal did not reach a majority (found=0/9 best_votes=0/9)
Die VM erfüllt wohl: vendor=AMD cpu=0 pti=not-detected eben das "Feature" pti nicht. Ich habe den aktuellen linux und meinen alten linux-next getestet, beide mit obigem Output. Deshalb haben diese Versuche wohl keine Relevanz.
- DiagSpill (CVE-2026-74469)
Setzt wohl bestimmte Profile der o.a. Distributions-Umgebungen voraus. Mit meinen bescheidenen Python-Kenntnissen - und der Zeit die ich aufzuwenden bereit bin! - sind mir Tests des PoCs nicht möglich. Das es in einer VM geschieht kommt hinzu.
//Edit: die üblichen Fipptehler<g> und Formatierungs-Dinge...
Ich setze den Thread wohl dann auch in ein paar Tagen auf "gelöst", da es m.E. Archlinux nicht (mehr) betrifft.