pedit COW & DirtyClone: zwei kritische Linux-Kernel-Lücken 2026

Unsicher, welche Ihrer Server diese Kernel-Lücken betreffen? Wir erkennen und priorisieren CVEs systemübergreifend und patchen im SLA - siehe CVE-Monitoring und Managed Operations, oder direkt ein Erstgespräch vereinbaren.

Innerhalb weniger Wochen sind 2026 zwei Linux-Kernel-Lücken zur lokalen Rechteausweitung veröffentlicht worden, die nach demselben Muster funktionieren: CVE-2026-46331 (Spitzname „pedit COW") und CVE-2026-43503 (von den Findern „DirtyClone" getauft). Beide erlauben es einem lokalen Nutzer mit niedrigen Rechten, über eine Beschädigung des Page Cache zu root zu werden. Und beide sind dort besonders brisant, wo unprivilegierte User-Namespaces aktiv sind: auf Container- und Multi-Tenant-Hosts, in Proxmox-LXC-Umgebungen und in Kubernetes.

Dieser Beitrag ordnet beide Lücken technisch sauber ein (Stand Juni 2026), zeigt, wer betroffen ist und wie Sie patchen - und welche Sofort-Mitigationen die Zeit bis zum Wartungsfenster überbrücken.

Inhaltsverzeichnis

• Was ist passiert: zwei Kernel-LPEs in einer Welle
• CVE-2026-46331: pedit COW im Detail
• CVE-2026-43503: DirtyClone im Detail
• Die gemeinsame Gefahr: Page-Cache-Poisoning und Container-Eskalation
• Betroffenheit prüfen und patchen
• Sofort-Mitigation ohne langes Wartungsfenster
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Was ist passiert: zwei Kernel-LPEs in einer Welle

Beide Lücken sind lokale Privilege-Escalation (LPE): kein Angriff aus dem Internet, sondern der Schritt vom einfachen Nutzer (oder kompromittierten Dienst, oder Container) zu vollen root-Rechten. Genau dieser Schritt verwandelt einen kleinen Einbruch in eine vollständige System-Übernahme.

• CVE-2026-46331 - „pedit COW" sitzt in der Traffic-Control-Aktion act_pedit des Kernel-Subsystems net/sched. Veröffentlicht über die Linux-CNA bei NVD/MITRE am 16. Juni 2026 (Red-Hat-Erstveröffentlichung am 18. Mai 2026).
• CVE-2026-43503 - „DirtyClone" sitzt in den Hilfsfunktionen zum Übertragen von skb-Fragmenten im ESP/XFRM-Eingangspfad. Veröffentlicht am 23. Mai 2026, vom Sicherheitsteam von JFrog „DirtyClone" benannt.

Die Namensnähe zur „Dirty"-Familie ist kein Zufall: Wie Dirty COW (2016) und DirtyPipe (2022) sind beide im Kern Page-Cache-Schreibprimitive. Es sind aber eigenständige, neue Schwachstellen in anderen Subsystemen - keine Aliase und keine Wiederkehr der alten CVEs.

CVE-2026-46331: pedit COW im Detail

act_pedit ist der Paket-Editor der Linux-Traffic-Control: Er schreibt gezielt Bytes in durchlaufende Netzwerkpakete. Der Fehler liegt in einer partiellen Copy-on-Write-Berechnung: Der beschreibbare Bereich des Socket-Buffers (skb) wird ohne den Laufzeit-Offset berechnet, den sogenannte typed keys hinzufügen. Das Ergebnis ist ein Out-of-Bounds-Write (CWE-787, begünstigt durch einen Integer-Überlauf, CWE-190) in eine geteilte Speicherseite - der Page Cache wird beschädigt.

Praktisch lässt sich daraus root machen, indem die gecachte Version einer setuid-root-Binary wie /bin/su vergiftet wird - dasselbe Vorgehen wie bei DirtyPipe. Eingeführt wurde der Bug mit Kernel 5.18. Bewertet ist er mit CVSS 7.8 (HIGH) durch die kernel.org-CNA und NVD (Vektor AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H); Red Hat führt 6.7 (Important), weil dort CAP_NET_ADMIN als Voraussetzung angesetzt wird. Diese Fähigkeit ist auf vielen Systemen über unprivilegierte User-Namespaces erreichbar - was die niedrigere Hürde des kernel.org-Scores erklärt.

CVE-2026-43503: DirtyClone im Detail

Bei DirtyClone versäumen zwei Hilfsfunktionen, beim Verschieben von Fragmenten zwischen Socket-Buffers (etwa beim fclone-Klonen von Paketen im ESP/XFRM-Eingangspfad) das Bit SKBFL_SHARED_FRAG weiterzugeben. In der Folge werden datei-gestützte Page-Cache-Seiten als beschreibbare Paketdaten behandelt - der Kernel schreibt also in Seiten, die eigentlich schreibgeschützte, root-eigene Dateien abbilden (CWE-664).

Das Resultat ist eine Rechteausweitung zu root mit möglichem Container-Escape. Bewertet ist DirtyClone mit CVSS 8.8 (HIGH) durch die kernel.org-CNA - mit dem wichtigen Detail S:C (Scope Changed), das den Container-Ausbruch widerspiegelt; Red Hat führt 7.0. Der Bug existiert seit etwa Kernel 3.9 und wurde im Mainline am 21. Mai 2026 gefixt (erstes Release-Tag v7.1-rc5). Details in der NVD-Aufzeichnung.

Die gemeinsame Gefahr: Page-Cache-Poisoning und Container-Eskalation

Beide Lücken sind im Kern dasselbe Werkzeug: ein Schreibzugriff in den Page Cache dort, wo er nicht hingehört. Wer in die gecachte Kopie einer schreibgeschützten, root-eigenen Datei schreiben kann, kann eine setuid-Binary umschreiben und sich root verschaffen - der bewährte DirtyPipe-Angriffsweg.

Der eigentliche Multiplikator sind unprivilegierte User-Namespaces. Sie geben einem normalen Nutzer im eigenen Namespace Fähigkeiten wie CAP_NET_ADMIN und damit Zugang zu den verwundbaren Pfaden. Auf gemeinsam genutzten Hosts wiegt das doppelt: Container (LXC, Docker, Kubernetes) teilen sich einen Kernel mit dem Host. Eine Kernel-LPE bedeutet dort potenziell den Ausbruch aus dem Container und die Übernahme des gesamten Hosts - inklusive aller Nachbar-Mandanten. Für Betreiber von Proxmox-LXC-Hosts und Kubernetes-Clustern ist das der Grund, warum diese beiden CVEs ganz oben auf der Patch-Liste stehen.

Betroffenheit prüfen und patchen

Betroffen ist im Grunde jede aktuelle Distribution mit verwundbarem Kernel - pedit COW ab 5.18, DirtyClone ab etwa 3.9, jeweils bis zur gefixten Version. Der Status der großen Distributionen (Stand Juni 2026):

• CVE-2026-46331 (pedit COW): gefixt in RHEL 8/9/10 (RHEL 6/7 nicht betroffen), in den Ubuntu-LTS-Kerneln und in Debian 13 sowie im Mainline/Stable. Vendor-Status: Ubuntu, Red Hat.
• CVE-2026-43503 (DirtyClone): im Mainline am 21. Mai 2026 gefixt (v7.1-rc5), mit Backports für Ubuntu (24.04/22.04 u. a.), Debian (bullseye/bookworm/trixie) und RHEL 9/10. Vendor-Status: Ubuntu, Debian.

Konkret: laufende Kernel-Version mit uname -r ermitteln, gegen die als gefixt markierte Version der eigenen Distribution abgleichen, das Kernel-Paket aktualisieren und neu starten (oder Live-Patch einspielen). Bei einer größeren Server-Flotte ist genau das der Knackpunkt - zu wissen, welche Hosts überhaupt einen verwundbaren Kernel fahren. Diese Inventarisierung in Stunden statt Tagen leistet ein kontinuierliches CVE-Monitoring.

Sofort-Mitigation ohne langes Wartungsfenster

Wenn ein sofortiger Reboot nicht möglich ist, senken zwei Maßnahmen das Risiko deutlich - als Brücke, nicht als Ersatz für den Patch:

• Unprivilegierte User-Namespaces deaktivieren. Auf Debian/Ubuntu: sysctl -w kernel.unprivileged_userns_clone=0. Das schließt den Hauptweg, über den ein normaler Nutzer beide Lücken erreicht. Achtung: Manche Container-Runtimes brauchen User-Namespaces - vorher testen.
• act_pedit-Modul sperren (gegen pedit COW). Wer tc pedit nicht nutzt, kann das Modul per Blocklist am Laden hindern und so den verwundbaren Pfad ganz entfernen.

Ergänzend gilt das Übliche: Wer Container ausführen oder CAP_NET_ADMIN erlangen darf, sollte streng begrenzt sein. Diese Stellschrauben gehören in eine gehärtete Grundkonfiguration - prüfen lässt sich der Stand mit einem Security-Audit.

Unser Vorgehen bei WZ-IT

Wir behandeln Kernel-CVEs als Teil des Betriebs, nicht als Einzelfeuerwehr - im Rahmen von Managed Operations:

1. Erkennen und priorisieren. Das CVE-Monitoring gleicht neue CVEs gegen den realen Bestand ab und priorisiert nach CVSS und Erreichbarkeit - eine local-only-LPE auf einem isolierten Host ist etwas anderes als dieselbe Lücke auf einem Multi-Tenant-LXC-Host.
2. Patchen im SLA. Kernel-Updates werden getestet, in Wartungsfenstern ausgerollt und per Reboot oder Live-Patch aktiv - mit definierten Reaktionszeiten statt „irgendwann".
3. Härten. Gehärtete Baselines (deaktivierte unprivilegierte User-Namespaces wo möglich, minimale Modulauswahl, Begrenzung von CAP_NET_ADMIN) reduzieren die Angriffsfläche dauerhaft - besonders auf Proxmox-Container-Hosts.

So wird aus „zwei neue Kernel-CVEs" eine kontrollierte Routine statt einer Nachtschicht.

Weiterführende Guides

• Linux-Kernel-Schwachstellen 2026: Patch-Management als Chefsache - der strategische Rahmen rund um Kernel-Updates.
• CVE-Monitoring für self-hosted Software - wie kontinuierliche Schwachstellen-Überwachung im Unternehmen funktioniert.
• OPNsense 26.1.8: CVE-2026-44194/45158 und Patch-Management - dasselbe Prinzip am Beispiel der Firewall.
• CVE-Monitoring-Hub - unser Ansatz für kontinuierliche Schwachstellen-Erkennung und Patching.

Bevor die nächste Kernel-Lücke kommt: Wir überwachen Ihre Systeme auf CVEs, priorisieren nach echtem Risiko und patchen im SLA. Jetzt Erstgespräch vereinbaren.

Quellen

• NVD: CVE-2026-46331 (pedit COW)
• NVD: CVE-2026-43503 (DirtyClone)
• MITRE/CVE.org: CVE-2026-46331
• MITRE/CVE.org: CVE-2026-43503
• Ubuntu Security: CVE-2026-46331
• Red Hat Security: CVE-2026-46331
• Debian Security Tracker: CVE-2026-43503