Sicherheitsforscher sind auf eine neue, pedit COW genannte, Schwachstelle CVE-2026-46331 gestoßen, es erlaubt, Speicherinhalte zu missbrauchen, um normalen Nutzern Root-Rechte zu verschaffen.
Das Thema köchelt bereits seit einigen Tagen auf X, nachfolgender Tweet greift den Sachverhalt auf.
Die Schwachstelle pedit COW (CVE-2026-46331) wurde mit einem CVSS 3.1 Score von 7.8 als High eingestuft. Die Sicherheitslücke ermöglicht es einem unprivilegierten lokalen Benutzer, Root-Rechte zu erlangen, indem sie einen Fehler in der Aktion act_pedit des Traffic-Control (tc) ausnutzt. Dadurch wird der gemeinsame Page-Cache korrumpiert, anstatt eine COW-Kopie durchzuführen. Der Angreifer vergiftet im RAM ein setuid-Binary (/bin/su), ohne die Festplatte zu verändern. Die Integritätsprüfungen laufen ins Leere.
Die Schwachstelle wurde am 16. Juni 2026 bekannt, inzwischen ist ein öffentlicher PoC verfügbar. Betroffen sind RHEL 8-10, Debian 11-13 und aktuelle Ubuntu-Versionen. Es wurde aber ein Patch veröffentlicht. Zur Absicherung wird im Tweet die Deaktivierung unprivilegierter User-Namespaces oder des Moduls act_pedit empfohlen.
MVP: 2013 – 2016
beide CVE ( auch DirtyClone ) sind bereits ab Kernel 7.1 gefixt.
siehe Commits:
pedit: 899ee91156e5 net/sched: fix pedit partial COW leading to page cache corruption
und,
DirtyClone:
f84eca581739 net: skbuff: preserve shared-frag marker during coalescing
48f6a5356a33 net: skbuff: propagate shared-frag marker through frag-transfer helpers
e9096a5a170e xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags()
f4c50a4034e6 xfrm: esp: avoid in-place decrypt on shared skb frags
aa54b1d27fe0 rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present
Und bei älteren Kernels? Ist ja nicht so, dass die nicht mehr eingesetzt werden, die 7er Reihe ist ja noch nicht so alt. Und seit wann existiert die Lücke, auch schon wieder 10 Jahre?
Geduld. Wenn ein Kernel den LTS-Support hat bekommt er auch so einen Fix. Einfach mal einlesen.
Wollte gerade auch schreiben – es sind eigentlich zwei
https://www.scworld.com/news/2-linux-kernel-flaw-pocs-published-enabling-local-privilege-escalation
Der Aktualität und Vollsändigkeit halber – neben "pedit COW" reiht sich DirtyClone seit 3-4 Tagen in die Frag-Reihe bei Linux ein:
Die Familie ist somit technisch eng verwandt. Folgernd ähnelt sich Mitigation: Module lassen sich zur Laufzeit blacklisten oder deaktivieren, gegen DirtyClone und "pedit COW" helfen:
Dazu die Liste der deaktivierten Module gegen "Pedit Cow" oder "DirtyClone":
Pedit COW
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/Hotfix-OFF_pedit.conf>
Dirty Clone
echo 'install esp4 /bin/true' | sudo tee /etc/modprobe.d/Hotfix-OFF_esp.conf
echo 'install esp6 /bin/true' | sudo tee -a /etc/modprobe.d/Hotfix-OFF_esp.conf
echo 'install rxrpc /bin/true' | sudo tee -a /etc/modprobe.d/Hotfix-OFF_esp.conf
Ein französicher Beitrag dazu lautet: "Y'en a tellement on arrive plus a suivre" – übersetzt grob: Gibt's so viele, da kommen wir nicht hinterher. Ein nettes Summary mit Deep Dive existiert bei Cybersec Guru, der von Günter verlinkte Twitter-Clone Beitrag entwickelt sich ebenso.
Anmerkung: Wenn wir für eine saubere IT Zeit bekommen wären idealerweise alle nicht benötigten Module restriktiv nicht "enabled", ladbar oder geblacklisted. Ich nutze in meinen Audits und Configs ohne jede Störung ca. 50 Module die ich einfach verbiete. Dies minimiert die Angriffsfläche bevor ein Fehler gefunden wird, ist einfach, schlanker – und eine gute "TOM" (technisch organisatorische Maßnahme) die bis auf etwas Freiraum für engagierte IT-Mitarbeiter nichts kostet. Es gibt Angriffsflächen und Modulnamen deren Nutzen, Protokoll oder Namen auch ich nicht einmal kenne und seit Jahren nie (!) benötigte. Schon bei Löwenzahn mit
Peter Lustig hiess das am Ende immer "Abschalten jetzt".
blöde Frage: wie erkennt man alle nicht benötigen Module? manche werden ggf ja auch bei Bedarf geladen.
@Daniel – Mehrere Optionen, dies muss adaptiert, getestet und auf Situation angepasst werden. Früher ™ hat man in eine Installation nur Module installiert oder kompiliert welche benötigt wurden. Dies ist der Gedanke Whitelist. Seit man "zu bequem" wurde ist der Gedanke jetzt Blacklist – die deaktivieren die nie genutzt werden (einfach CD rein, Weiter-Weiter-OK-Klicker, nicht nachdenken). Ziel ist der Minimalansatz und Verringerung der Angriffsfläche. Je weniger da ist – desto weniger ist nachladbar oder angreifbar. Somit bleibt zum Ausschluss von Modulen zB: 1. Erfahrung 2. Ermitteln von geladenen und genutzten Modulen 3. Testen.
Einstieg bieten die "Modules" nach erstem Setup oder Nutzung:
Dann selektieren und eigene Blacklists definieren, den Status Quo dabei berücksichtigen. Davon unberücksichtigt sind dann noch bereits einkompilierten Module. Ansonsten gesunder Server- & Menschenverstand:
Und jaa, das bedeutet im ersten Schritt ein Ruleset oder Pflege für deinen Serverbestand. Beispiele für unnötige Module eines typischen Produktiv-Servers:
Beispiel für fast nie genutzte aber Default geladene Module:
hallo,
danke für die Rückmeldung. Du hast damit natürlich vollkommen recht. Whitelist wäre auf jeden Fall besser. Danke für die Infos, hab mir eh schon gedacht, dass das nix ist, was man im Vorbeigehen macht.
Mit Bequemlichkeit hat das eher weniger zu tun. Distributoren wollen eine möglichst breite Nutzerbasis ansprechen und dem entsprechend liefern sie einen voll ausgestatteten Kernel aus, das meiste als kompiliertes Modul, was optional aber einfach nachgeladen werden kann.
Wer seine Anforderungen kennt und die Konsole nicht scheut, könnte sich seinen Kernel hingegen selber konfigurieren und alles nicht benötigte in der config ausschalten oder — besser(?) — das Nachladen von Modulen gänzlich abschalten und die notwendigen Dinge fest einkompilieren.
Jedenfalls Bequemlichkeit seitens der Distributoren sehe ich da in erster Linie nicht, das ist ein wenig kurz gedacht.
@M.D. "Bequemlichkeit seitens der Distributoren" – Danke, war evtl. undeutlich. Keinesfalls würde ich OSS, Community oder Distris bequem nennen wollen. "Zu bequem" galt eher als Referenz zu Nutzererwartung: Der Typus "CD rein, OK-Klicker".
Ein gutes System benötigt einfach seine Zeit für Install & Config: Du sagst ja selbst ;-) "Wer seine Anforderungen kennt . Und genau die achte ich – ebenso wie die Distris. Den hier wird verstanden das gut Ding Weile haben will (meine Systeme sind auch nicht "perfekt" – jedoch recht gut, so "2 bis 2-" vielleicht…)
Nur weil etwas in den kernel.org patches vom 19.06. z. B. in 6.18.36 gefixed wurde ist es noch lange nicht bei den real laufenden Kernels der Distributionen angekommen.
Alles muss erst einmal vernünftig ausgetestet und danach ggf. auch noch zertifiziert worden sein.
Ubuntu ist in der Standardkonfiguration anscheinend zufällig nicht von pedit Cow betroffen. Seine Kernels selbst dagegen schon.
Redhat hat derzeit lediglich als Mitigation das Laden des betroffene act_pedit geblockt.
Debian hat den Patch bisher auch gerade einmal für trixie (security) ausgerollt.
Mit Windows wsl nutzen alle Distributionen derzeit kernel 6.18.32.2 nach einem
wsl --update
Man sollte deshalb unter Windows in '%USERPROFILE%\\.wslconfig' mit
[wsl2]
# Unfixed in wsl 2.7.0.8 / 6.18.32.2:
# CVE-2026-43503(DirtyClone 6.18.33)
# CVE-2026-46300(fragnesia 6.18.33)
# CVE-2026-46243(CIFSwitch 6.18.34)
# CVE-2026-46331(peditCOW 6.18.36)
kernelCommandLine="module_blacklist=esp4,esp6,rxrpc,cifs,act_pedit"
die in der Regel überhaupt nicht genutzten vulnerablen Module sperren. Mitigations in den Distributionen selbst funktionieren hier nicht.
Auch nach
wsl --update --pre-release
muss man mit wsl 2.7.0.10 / kernel 6.18.33.2 derzeit weiterhin die letzten beiden Module "cifs,act_pedit" sperren um zumindest nicht durch die bekanntesten POCs direkt angreifbar zu sein.
Hmm ich denke Debian, Ubuntu und Konsorten wie RHEL fixen das auch relativ schnell^^
meine 2Ct – müßt Ihr nicht lesen, da es nicht zur Problemlösung beiträgt.
zu Norddeutsch v. 28.06. 21:31 "Ein französicher Beitrag dazu lautet: "Y'en a tellement on arrive plus a suivre" – übersetzt grob: Gibt's so viele, da kommen wir nicht hinterher".
Nutze Ubuntu ab 2018.04, z.Zt. 2022.04 LTS, in der Qualifikation Anfänger – seit 1990 aber Win 3.1 incl. Softwareprogrammierung. Jetzt mit über 70J muß das Rack einfach laufen – Tiefe ist nicht mehr.
Zu meinem Thema:
In den letzten ca. 3-5Monaten habe ich jeglichens Vertrauen in diese Software verloren: Zuerst das Zitat v Norddt., dazu Jahre alte ungepatchte Sicherheitslücken, die Oberfläche „Ubuntu Software", auf die in keiner Weise Verlaß ist – also schon bei der Upd-Verwaltung versagt – durchgeführte Upds werden als installiert angezeigt, sind es aber nicht (besonders bei Firefox seit Monaten aufgefallen), Thunderbird hat schon ewig kein Upd mehr erhalten (taucht noch nicht mal bei "Ubuntu-Software" auf), od. diese Upds werden einfach im Hintergrund reingerückt (mal mit, mal ohne Passworteingabeaufforderung), ohne das man das will (Computersabotage)(die ersten sind doch sowieso fehlerhaft), anderes Bsp.: Vi-Improved .. Textverarbeitung: allein 15 ! Upds seit 03.06.2024 (für 'ne einfache Textverarbeitung), usw, usw.
Da haben sich wohl manche auf ihren Lorbeeren od. der, immer propagierten, aber vermeintlichen Sicherheit ausgeruht.
Ich will nicht weiter nerven, mußte einfach mal raus.
Servus,
also dass da mal mit und ohne Adminpasswort-Abfrage Updates "reingedrückt" werden, kommt mir komisch vor. Das kann ich mir nur bei Flatpak oder vlt. Snap so vorstellen, nicht aber bei Paketen die direkt aus der Paketverwaltung kommen. (.DEB / APT). Allerdings bin ich schon lange kein Ubuntu-Mann mehr. (Deshalb ist meine Aussage vermutlich mit etwas Vorsicht zu genießen). Mir gefällt deren Ansatz nicht (Ubuntu). Ein Grund, weshalb ich keine Derivate einsetze und immer lieber beim Kern bleibe (Debian).
Ist aber natürlich eine persönliche Befindlichkeit. Wenn du Ubuntu schon so lange nutzt, verstehe ich auch, dass du das nicht mehr ändern wollen würdest.
Es ist Snap. Hatte bis Juni 2025 auf Anraten vieler eine PPA-Installation, aber die wurde ja nicht mehr unterstützt.
Danke für die geteilten Erfahrungen, @Wolf789.
Bei Ubuntu gab es immer mal wieder Qualitätsprobleme, die momentan vielleicht deshalb stärker ausfallen, weil man dort intensiver mit KI befasst ist. Wenn es ein LTS-Ubuntu sein soll, kann ich nur Linux Mint empfehlen, weil Snap per default deaktiviert ist, die Desktop-Umgebungen benutzerfreundlich vorkonfiguriert sind und es offenbar so etwas wie eine Qualitätskontrolle gibt (weniger Probleme als bei Ubuntu).
Sollte Sie Daniel. in Versuchung geführt haben: Die haben auch ein gut funktionierendes Debian mit Cinnamon-Desktop. ;-)
Ich selbst verwende (noch) Mint-Ubuntu, da der von mir bevorzugte Xfce-Desktop damit besser läuft als mit Debian. (Mal schauen, wie das nach der Umstellung auf Wayland aussieht).
Herzlichen Dank für die Info.
Mint wollt ich schon mal ausprobieren, kam aber bisher nicht dazu.
@Wolf789 Zum Test – Damit ausprobieren wenig Aufwand und keine Installation bedeutet: Mirrorserver zu startbaren Life ISOs mit wählbarem Desktop.
Einfach auf DVD brennen / USB-Stick kopieren, life booten & anschauen. SHA & sig überprüfen. Dies allein ist jedoch keine fertige Einfach-Sorglos-Lösung… Auch wenn das "Rack einfach laufen" soll – jedes OS, jeder Desktop hat zicken. Linux Mint ist ebenso eine Option. Helfe gern bei Fragen.
Auch meinen herzlichen Dank
@Wolf789 Sorry, hatte ich vergessen zu erwähnen:
Unter https://distrosea.com/de kann man viele Distros mit unterschiedlichen Desktop-Umgebungen online ausprobieren.