Das Unangenehme an CVE-2026-46331 (Spitzname „pedit COW”) ist nicht, dass sich ein lokaler Nutzer zu root hochzieht – das kennen wir seit Copy Fail und Dirty Frag. Das Unangenehme ist, dass dein Integritäts-Check dabei grün bleibt. Der Exploit verändert nicht die Datei /bin/su auf der Platte, sondern deren bereits geladene Kopie im Page Cache des Kernels. AIDE, Tripwire oder ein rpm -V sehen eine saubere Binary, während daneben schon eine root-Shell offen ist. Genau das macht die Lücke für jeden gemeinsam genutzten Server zum Problem.
Betroffen ist praktisch jeder Linux-Server mit halbwegs aktuellem Kernel: der vServer beim Hoster, die Cloud-VM, der Webserver, der Proxmox-Host im Heimnetz. Aus der Ferne allein lässt sich die Lücke nicht ausnutzen, der Angreifer braucht lokalen Zugriff – einen Shell-Account, einen kompromittierten Dienst oder einen Container. Auf meinem netcup-vServer habe ich zuerst user.max_user_namespaces geprüft, denn ohne offene User-Namespaces läuft der öffentliche Exploit nicht. Der Wert stand auf 15000, also weit offen. Der Check dauert keine zwei Minuten, der Patch ist ein apt full-upgrade, und für ein späteres Wartungsfenster gibt es zwei Mitigationen, die sofort und ohne Reboot greifen.
Was ist CVE-2026-46331 („pedit COW”)?
Die Lücke steckt im Traffic-Control-Subsystem des Linux-Kernels, genauer in der Aktion act_pedit. pedit ist das Werkzeug, mit dem tc Paket-Header zur Laufzeit umschreibt. Beim Schreiben nutzt der Kernel Copy-on-Write (COW): Solange niemand schreibt, teilen sich mehrere Prozesse dieselbe Speicherseite; erst beim ersten Schreibzugriff wird eine private Kopie angelegt.
Der Fehler: tcf_pedit_act() berechnet den COW-Bereich einmal vor der Schleife über die Keys (über tcfp_off_max_hint) und übersieht dabei den Header-Offset, den typisierte Keys erst zur Laufzeit hinzufügen. Dadurch schreibt der Kernel in eine Seite, die er nie privatisiert hat – ein partielles COW, das in den gemeinsam genutzten Page Cache landet. Wer dort gezielt die zwischengespeicherte Kopie einer setuid-root-Binary wie /bin/su trifft, kann eigenen Code als root ausführen. Ein Container-Ausbruch ist ebenfalls möglich. Der Upstream-Fix (Commit 899ee91156e5, „net/sched: fix pedit partial COW leading to page cache corruption”) verschiebt die skb_ensure_writable()-Prüfung in die Key-Schleife und ergänzt eine Überlauf-Kontrolle auf der Offset-Berechnung.
Bei der Einstufung gehen die Quellen auseinander: Das NVD/kernel.org-Advisory vergibt nach CVSS 3.1 7.8 (High) und ordnet die Lücke als CWE-787 (Out-of-bounds Write) plus CWE-190 (Integer Overflow) ein. Canonical bewertet sie im Ubuntu-Advisory nach dem neueren CVSS-4.0-Schema mit 8.5 (High) – das höhere Schema gewichtet den Integritätsverlust am Page Cache stärker. In beiden Fällen bleibt es eine ernste lokale Rechteausweitung. In der CISA-KEV-Liste steht die Lücke (Stand dieses Artikels) noch nicht, eine aktive Ausnutzung in freier Wildbahn ist also nicht bestätigt. Ein lauffähiger Proof-of-Concept (packet_edit_meme) kursiert allerdings seit dem 17. Juni 2026, einen Tag nach Bekanntwerden der CVE – die Hürde ist damit niedrig.
Bist du betroffen?
Verwundbar bist du, wenn drei Dinge zusammenkommen: ein Kernel im betroffenen Bereich, ein ladbares act_pedit-Modul und offene unprivilegierte User-Namespaces. Fehlt eine der Bedingungen, läuft der öffentliche Exploit nicht.
Zuerst die laufende Kernel-Version und die installierten Kernel-Pakete:
uname -r
dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'Dann die beiden Exploit-Voraussetzungen. Ist das Modul auf dem System überhaupt vorhanden und ladbar?
grep -E '^act_pedit ' /proc/modules || echo "act_pedit aktuell nicht geladen"
modprobe -n -v act_peditUnd sind unprivilegierte User-Namespaces offen? Ein Wert größer 0 heißt: offen.
sysctl user.max_user_namespacesDer verwundbare Code liegt etwa ab Kernel 5.18 im Mainline und wurde vor 7.1-rc7 gefixt. Über die Stable-Branches reichen die Backports bis auf ältere LTS-Linien zurück (4.19.244+, 5.4.195+, 5.10.117+, 5.15.41+, 5.17.9+, je nach Distribution).
Gepatchte Versionen
Liegt deine Version unter dem jeweiligen Stand, musst du updaten. Die für Server relevanten Stände:
| Distribution | Linie | Gepatcht ab / Advisory |
|---|---|---|
| Upstream | Mainline | 7.1-rc7 (Fix-Commit 899ee91156e5) |
| Debian 13 (Trixie) | linux | DSA-6355-1 (21.06.2026) |
| Ubuntu | siehe Advisory | per-Release im Ubuntu-Advisory |
| RHEL 9 | kernel | RHSA-2026:27789 |
| RHEL 8 | kernel | RHSA-2026:27353 |
| RHEL 10 | kernel | RHSA-2026:27288 |
| AlmaLinux 8 | kernel | ALSA-2026:27353 (22.06.2026) |
Die vollständige Ubuntu-Liste inklusive aller Cloud-Kernel (AWS, Azure, GCP, Oracle) und HWE-Varianten steht im verlinkten Advisory. Auf RHEL-Derivaten ist der Exploit dort am zuverlässigsten, wo User-Namespaces standardmäßig offen sind.
Fix: Kernel patchen
Der saubere Weg ist das Kernel-Update plus Reboot. Der bereits geladene Kernel im Speicher bleibt sonst verwundbar – und genau dort, im Page Cache, setzt der Angriff an.
Debian / Ubuntu / Proxmox:
sudo apt update && sudo apt full-upgrade
sudo rebootRHEL / AlmaLinux / Rocky:
sudo dnf update 'kernel*'
sudo rebootNach dem Neustart prüfst du mit uname -r, ob der gepatchte Kernel läuft. Bei einem gemieteten Root-Server oder einer Cloud-VM lohnt vorher der Blick, ob dein Hoster den Reboot über ein eigenes Panel erwartet oder ein simples reboot über die SSH-Sitzung reicht. Bei manchen Anbietern bootet sonst ein alter Hoster- oder Rescue-Kernel, und du bist trotz Update wieder verwundbar.
Sofort-Mitigation ohne Reboot
Ein Reboot heißt bei einem Produktiv-Server: Wartungsfenster, Ankündigung, Daumendrücken beim Hochfahren. Bis dahin kannst du den Exploit-Pfad an zwei Stellen kappen, beide ohne Neustart. Es reicht eine der beiden, weil der Angriff beide Voraussetzungen gleichzeitig braucht.
Die für die meisten Server schonendere Variante ist, das verwundbare Modul zu blockieren:
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.confSolange act_pedit nicht schon geladen ist (siehe Check oben), verhindert das ein Laden bei Bedarf. Auf einem normalen Server brauchst du tc act pedit praktisch nie – nur fortgeschrittenes Traffic-Shaping oder bestimmte CNI-Plugins nutzen es.
Die zweite Variante schließt unprivilegierte User-Namespaces. Der Befehl unterscheidet sich nach Distribution:
# RHEL / AlmaLinux / Rocky
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf
sudo sysctl --system# Debian / Ubuntu
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf
sudo sysctl --systemAchtung: User-Namespaces zu schließen bricht rootless Container (rootless Podman und Docker), Teile von Flatpak und manche Browser-Sandboxes. Wenn auf der Kiste solche Workloads laufen, nimm die Modul-Blockade statt der userns-Variante. Nach dem Kernel-Patch entfernst du die Mitigation wieder (sudo rm /etc/sysctl.d/99-pedit-cow.conf bzw. die modprobe.d-Datei) und lädst die sysctl-Konfiguration neu.
Fazit
pedit COW ist gefährlich, weil es leise ist: Die manipulierte /bin/su lebt nur im Page Cache, deine Datei-Integritäts-Checks schlagen nicht an. Wer mehrere Nutzer, erreichbare Dienste oder Container auf einer Maschine hat, sollte das nicht ins nächste Quartal schieben. Mein konkreter Rat: Kernel patchen und rebooten, und wenn das Wartungsfenster erst später kommt, heute das act_pedit-Modul blockieren – das kostet auf einem normalen Server nichts und schneidet den öffentlichen Exploit sofort ab.
Wer Copy Fail, Dirty Frag und ssh-keysign-pwn noch offen hat, erledigt alle vier Kernel-Lücken im selben Durchgang: ein full-upgrade, ein Reboot, danach pro CVE kurz gegen das Advisory deiner Distribution gegenprüfen.
Häufige Fragen
Warum sehen meine Integritäts-Checks (AIDE, Tripwire) nichts? ▾
Weil der Angriff die Datei auf der Platte nicht anfasst. Er verändert die bereits in den Page Cache geladene Kopie der Binary im Kernel-Speicher. Werkzeuge wie AIDE, Tripwire oder rpm -V vergleichen Prüfsummen der Dateien auf dem Datenträger – die bleiben unverändert und korrekt. Genau das ist die Pointe der Lücke: Sie umgeht On-Disk-Integritätsprüfungen vollständig. Verlässlich entdecken lässt sich der Angriff so kaum; der einzige saubere Schutz ist patchen oder mitigieren, bevor er passiert.
Muss ich patchen, wenn nur ich Zugriff auf den Server habe? ▾
Auf einem echten Single-User-System ohne erreichbare Dienste ist das Risiko gering, weil der Angriff lokalen Zugriff braucht. Sobald aber öffentlich erreichbare Software läuft (Webserver, Mailserver, eine App mit Code-Ausführung) oder mehrere Personen einen Account haben, solltest du zeitnah handeln. Bei gemieteten vServern weißt du zudem nie sicher, was sonst noch auf der Maschine passiert – im Zweifel patchen.
Reicht es, das act_pedit-Modul dauerhaft zu blockieren statt zu patchen? ▾
Als Übergangslösung bis zum Wartungsfenster: ja, das schneidet den bekannten Exploit-Pfad ab. Als Dauerzustand ist es kein Ersatz für den Patch. Der Fehler sitzt im Kernel selbst, und es ist nicht ausgeschlossen, dass die fehlerhafte COW-Logik über einen anderen Weg erreichbar wird. Sieh die Modul-Blockade als das, was sie ist: ein sauberer Riegel, der dir Zeit kauft, nicht die Reparatur.
Bricht mir das Deaktivieren von User-Namespaces meine Container? ▾
Ja, wenn du rootless Container fährst. Rootless Podman und Docker setzen auf unprivilegierte User-Namespaces; mit user.max_user_namespaces = 0 bzw. kernel.unprivileged_userns_clone = 0 starten sie nicht mehr. Klassische root-Container (Docker mit Daemon als root, LXC/LXD privilegiert) sind nicht betroffen. Wenn rootless-Workloads laufen, nimm stattdessen die Modul-Blockade – die stört den Container-Betrieb nicht.
Ist die Lücke mit Copy Fail, Dirty Frag oder ssh-keysign-pwn verwandt? ▾
Nur insofern, als alle vier 2026 aufgetaucht sind und lokalen Zugriff voraussetzen. Technisch sind sie verschieden: Copy Fail sitzt in der Krypto-API, Dirty Frag in IPsec/ESP, ssh-keysign-pwn im ptrace-Pfad, pedit COW im Traffic-Control-Code. Jede hat eine eigene Mitigation. Ein aktuelles Kernel-Update deckt oft mehrere ab, aber verlass dich nicht darauf – prüfe pro CVE gegen das Advisory deiner Distribution.