Security

pedit COW CVE-2026-46331: Linux prüfen, mitigieren und patchen

pedit COW betrifft Linux-Kernel, Hosting-, Container- und CI-Systeme. Patchstände, Angriffspfad, Mitigation und Reboot-Prüfung.

Von Moritz Mantel · Veröffentlicht: · Aktualisiert:

Stand: 08.07.2026, 12:10 Uhr CEST. Debian bleibt zweigeteilt: Bookworm Security und Trixie Security sind gefixt, Bullseye nur im separaten linux-6.1-Security-Zweig. Der klassische Bullseye-linux-Zweig bleibt verwundbar. Ubuntu hat weiter keine sichtbaren Fixed-Zeilen bei den unterstützten Kernel-Tracks. Neu seit dem letzten Abgleich: Oracle führt zusätzliche UEK-Errata für OL7/8/9/10, der CVEProject-Record wurde am 07.07. aktualisiert und nennt die Upstream-/Stable-Fixschwellen 6.12.94, 6.18.36, 7.0.13 und 7.1. CloudLinux hat seine Seite am 07.07. geändert, die KernelCare-Patch-IDs bleiben aber gleich. SUSE bleibt insgesamt Pending; dort stehen veröffentlichte Paketlisten und In progress-Status teilweise nebeneinander. Entscheidend bleibt: Ist dein laufender Kernel gefixt, ist act_pedit wirksam blockiert, oder ist der User-Namespace-Pfad wirklich geschlossen?

Kurzfassung

  • Worum es geht: pedit COW, CVE-2026-46331, ist eine lokale Rechteausweitung im Linux-Kernel. Der Bug sitzt im Traffic-Control-Modul act_pedit im Bereich net/sched.
  • Remote allein ausnutzbar: Nein. Ein Angreifer braucht lokale Code-Ausführung, zum Beispiel einen Shell-Account, eine kompromittierte Webanwendung, einen CI-Job, Plugin-Code oder Code in einem Container.
  • Warum es trotzdem kritisch ist: Der öffentliche PoC packet_edit_meme macht aus einem unprivilegierten lokalen Benutzer Root, wenn Kernel, Modulstatus und User-Namespace-Policy passen.
  • Nicht dasselbe wie Dirty Frag oder Fragnesia: Die Fehlerklasse ist wieder Page-Cache-Corruption, der Einstiegspunkt ist aber ein anderer. Die Dirty-Frag-/Fragnesia-Blocklist für esp4, esp6, espintcp und rxrpc schützt nicht gegen pedit COW.
  • Typische Voraussetzungen: act_pedit ist vorhanden oder autoloadbar, unprivileged user namespaces sind nutzbar, und der Angreifer kann in einer User-/Network-Namespace-Welt CAP_NET_ADMIN bekommen.
  • Saubere Lösung: Vendor-Kernel aktualisieren, anschließend rebooten oder einen passenden Livepatch nachweisen. Ein installiertes Kernelpaket ohne gebooteten Kernel ist kein Fix.
  • Zwischenlösung: act_pedit blockieren oder unprivilegierte User-Namespaces einschränken. Beides kann legitime Workloads treffen: Traffic-Control-Regeln, Rootless Container, CI-Sandboxes, Browser-Sandboxing und Entwickler-Setups.
  • Nicht machen: Den öffentlichen PoC nicht auf Produktivsystemen starten. Er schreibt in die gecachte Kopie von /bin/su. Das ist kein harmloser Scanner.

Was ist pedit COW?

pedit steht hier nicht für einen Texteditor, sondern für die Packet-Editing-Action im Linux Traffic Control Framework. Mit tc können Pakete klassifiziert, geformt und verändert werden. Die Action act_pedit kann Header-Felder direkt im Paket ändern, zum Beispiel für spezielle Netzwerk-, QoS- oder Appliance-Setups.

Der Bug liegt in genau diesem “direkt ändern”. Der Kernel muss sicherstellen, dass der Speicherbereich, in den geschrieben wird, wirklich privat und beschreibbar ist. Das ist die Copy-on-Write-Idee: Wenn ein Speicherbereich geteilt ist, wird vor dem Schreiben eine private Kopie angelegt.

Bei CVE-2026-46331 hat tcf_pedit_act() den beschreibbaren Bereich zu früh berechnet. Typed Keys können zur Laufzeit noch einen Header-Offset hinzufügen. Dieser spätere Offset wurde in der alten Prüfung nicht sauber berücksichtigt. Das Ergebnis: Ein Teil des tatsächlichen Schreibbereichs war nicht per COW privatisiert. Der Kernel schrieb dann in Speicher, den er nicht exklusiv besaß.

Wenn dieser Speicher auf eine Page-Cache-Seite zeigt, wird es gefährlich. Der Page Cache hält gelesene Dateien im RAM. Ein unprivilegierter Prozess darf /bin/su oder andere SUID-Binaries zwar lesen, aber nicht verändern. Wenn der Kernel aber über einen falschen Paketpfad in die gecachte Datei-Seite schreibt, kann die RAM-Kopie kurzzeitig manipuliert werden, ohne dass die Datei auf der Platte verändert wurde.

Genau das nutzt der öffentliche PoC. Er überschreibt die gecachte ELF-Einstiegsstelle von /bin/su mit kleinem Shellcode für setgid(0), setuid(0) und execve("/bin/sh"). Der nächste Start von su läuft dann aus der manipulierten RAM-Kopie heraus als Root.

Datei-Hashes können dabei sauber aussehen. Der Angriff muss die Datei auf dem Storage nicht anfassen. Das ist derselbe unangenehme Grundmechanismus, der schon Copy Fail, Dirty Frag und Fragnesia aus Betriebssicht ernst gemacht hat.

Wie funktioniert der Angriff technisch?

Die kurze Version: Ein lokaler Prozess baut sich über unprivileged user namespaces eine eigene Netzwerk-Namespace-Umgebung, bekommt dort CAP_NET_ADMIN, konfiguriert eine tc-Regel mit act_pedit und bringt den Kernel dazu, über den fehlerhaften COW-Bereich in eine Page-Cache-Seite zu schreiben.

Grob sieht die Kette so aus:

  1. Der Angreifer hat lokale Code-Ausführung als normaler Benutzer.
  2. Er erstellt User- und Network-Namespaces.
  3. In dieser Namespace-Welt hat er CAP_NET_ADMIN.
  4. Damit kann er Traffic-Control-Actions konfigurieren.
  5. act_pedit bearbeitet ein Paket mit einem zur Laufzeit berechneten Offset.
  6. Die alte Kernel-Logik hat nicht den gesamten späteren Schreibbereich privatisiert.
  7. Der Write erreicht eine gemeinsam genutzte Page-Cache-Seite.
  8. Eine gecachte Kopie eines SUID-root-Binaries wird im RAM manipuliert.
  9. Beim nächsten Aufruf wird diese manipulierte Kopie ausgeführt.

Das ist bewusst keine Exploit-Anleitung. Für den Betrieb reichen die wichtigen Punkte: pedit COW ist lokal, nicht remote. Der Angreifer braucht aber keine echten Root-Rechte, wenn User-Namespaces offen sind. Das ist auf Servern mit Containern, CI, Hosting-Tenants oder Entwickler-Workloads keine theoretische Voraussetzung.

Ubuntu zeigt, warum die User-Namespace-Policy wichtig ist. Der PoC nennt Ubuntu 24.04.4 als ausnutzbar, wenn er über bestimmte AppArmor-Profile mit aa-exec läuft. Ubuntu 26.04 scheitert im PoC, weil die AppArmor-Restriktion für unprivilegierte unconfined Profile härter ist. Das ist aber keine pauschale Entwarnung für jeden Ubuntu-Kernel. Canonical markiert die betroffenen Kernel-Tracks trotzdem als verwundbar, bis ein passender Kernel-Fix aktiv ist.

Upstream-Fix und Kernelbereich

Der zentrale Upstream-Fix ist Commit 899ee91156e57784090c5565e4f31bd7dbffbc5a mit dem Titel net/sched: fix pedit partial COW leading to page cache corruption. Der Patch verschiebt die Prüfung mit skb_ensure_writable() in die Schleife pro Key, also an die Stelle, an der der tatsächliche Schreiboffset bekannt ist. Zusätzlich prüft der Fix Offset-Überläufe und behandelt negative Offsets über skb_cow().

Für unveränderte Upstream-Kernel nennt der öffentliche PoC den betroffenen Bereich grob von v5.18 bis vor v7.1-rc7. Das ist aber die PoC-Kurzform, nicht die ganze CVE-Landkarte. Der CVEProject-Record führt zusätzlich Stable-/LTS-Bereiche ab 4.19.244, 5.4.195, 5.10.117, 5.15.41 und 5.17.9 als betroffen, jeweils abhängig vom konkreten Stable-Backport. Im aktuellen Record sind die gefixten Upstream-/Stable-Schwellen für aktive Linien ausdrücklich bei 6.12.94, 6.18.36, 7.0.13 und 7.1 geführt. Für Distributionen ist die Upstream-Spanne deshalb nur eine Orientierung. Debian, Ubuntu, RHEL, AlmaLinux, Rocky, Oracle, SUSE, CloudLinux, Proxmox und Cloud-Kernel backporten Kernel-Fixes. Ein Kernel mit optisch alter Hauptversion kann gefixt sein, wenn der Vendor den Patch zurückgetragen hat. Umgekehrt hilft ein neu wirkender Kernel nicht, wenn genau dieser Backport fehlt.

Für selbst gebaute Kernel, Gentoo-Systeme oder Appliance-Kernel solltest du konkret prüfen, ob der act_pedit-Fix aus 899ee91156e5 enthalten ist oder ob der entsprechende Stable-Backport in deiner Linie gelandet ist.

Wer ist betroffen?

Betroffen sind Linux-Systeme mit verwundbarem Kernel, erreichbarem act_pedit-Pfad und lokalem Code-Ausführungskontext. Eine reine Aussage wie “Distribution X ist betroffen” reicht wieder nicht, weil Kernel-Flavour, Backports, Module, Livepatching und User-Namespace-Policies eine Rolle spielen.

UmgebungEinschätzungWorauf prüfen
DebianDebian Security Tracker: Bookworm Security ist ab 6.1.176-1 gefixt, Trixie Security seit 6.12.94-1; aktuell steht Trixie Security bei 6.12.95-1. Forky ist ab 7.0.13-1 und Sid ab 7.1.3-1 gefixt. Bullseye ist zweigeteilt: der klassische linux-Zweig bleibt verwundbar, linux-6.1 ist ab 6.1.176-1~deb11u1 gefixt.Nicht nur Debian-Version prüfen. Entscheidend sind Source-Paket, Security-Repo und laufender Kernel nach Reboot.
UbuntuCanonical bewertet CVE-2026-46331 als High. Die CVE-Seite wurde am 05.07. aktualisiert, markiert die sichtbaren unterstützten Kernel-Tracks, darunter 22.04, 24.04, 25.10 und 26.04, aber weiter als vulnerable.Pro Kernel-Flavour prüfen: generic, HWE, cloud, OEM, realtime, Livepatch. AppArmor-Userns-Härtung reduziert den PoC-Pfad, ersetzt aber keinen Kernel-Fix.
RHEL / OpenShiftRed Hat führt RHSB-2026-008 als Important. Seit dem Update vom 03.07. sind die Fixes für RHEL 8, 9 und 10 laut Bulletin vollständig veröffentlicht. OpenShift bleibt laut Red Hat Low severity, weil das verwundbare Modul nicht default geladen ist.Red-Hat-Bulletin, Errata und laufenden Kernel prüfen. Bei OpenShift Node-Kernel und MachineConfig-Rollout prüfen.
AlmaLinuxAlmaLinux hat Kernel-Errata für 8, 9 und 10 veröffentlicht.Mindestens kernel-4.18.0-553.136.1.el8_10, kernel-5.14.0-687.17.1.el9_8 oder kernel-6.12.0-211.26.1.el10_2, danach Reboot.
Rocky LinuxRocky hat RLSA-2026:27353, RLSA-2026:27789 und RLSA-2026:27288 veröffentlicht; die RLSA-Seiten wurden am 05.07. erneut aktualisiert.Rocky 8: 4.18.0-553.136.1.el8_10; Rocky 9: 5.14.0-687.17.1.el9_8; Rocky 10: 6.12.0-211.26.1.el10_2 oder neuer.
CloudLinuxCL7 ist laut CloudLinux nicht betroffen. CL7h, CL8, CL9, CL10 und CloudLinux for Ubuntu 22.04 sind betroffen. KernelCare-Livepatches sind laut CloudLinux seit 02.07. im Main Feed live.CL7h/CL8: CloudLinux-Zielstände kernel-4.18.0-553.137.1.lve... oder neuer. CL9/CL10 folgen AlmaLinux-Zielständen. KernelCare per kcarectl --patch-info nachweisen.
Amazon LinuxAWS führt CVE-2026-46331 mit Medium Severity. Die Amazon-Linux-CVE-Seite zeigte zum geprüften Stand AL2 Kernel-5.4, Kernel-5.10 und Kernel-5.15 Extra sowie AL2023 kernel, kernel6.12 und kernel6.18 als Pending Fix; AL2 Core steht auf Not Affected.ALAS-Seite und konkrete Kerneltracks prüfen. Nicht aus RHEL-, Alma- oder Rocky-Fixständen ableiten.
Oracle LinuxOracle führt CVE-2026-46331 als Important. Neben RHCK-Fixes für OL8 und OL9 (ELSA-2026-27353, ELSA-2026-27789) sind inzwischen UEK-Errata für OL7/8/9/10 sichtbar: ELSA-2026-50372, ELSA-2026-50373 und ELSA-2026-50374.RHCK/UEK getrennt prüfen. uname -r, rpm -q kernel kernel-uek und Oracle-CVE-/ELSA-Seiten abgleichen.
SUSE / openSUSE / SUSE Liberty LinuxSUSE bewertet das Thema als Important und führt den Gesamtstatus weiter als Pending. Liberty Linux 8/9/10, openSUSE Leap 15.6 und SUSE Linux Micro 6.0/6.1 sind mit veröffentlichten Fixes geführt. Bei SLES 15 SP6-LTSS, SLES/SAP 15 SP7 und mehreren Modulen stehen veröffentlichte Paketlisten und In progress-Status nebeneinander. SLES 16.0/16.1, openSUSE Leap 16.0 und Micro 6.2 stehen weiter auf affected.Produktgenaue SUSE-CVE-Seite prüfen. Liberty-Linux-EL-Fixstände nicht blind auf SLES, Micro oder openSUSE übertragen.
Fedora / Rolling ReleasesDer geprüfte Bodhi-Search lieferte keinen eigenen CVE-2026-46331-Updateeintrag. Rolling-Systeme müssen über Kernel-Update und Changelog geprüft werden.dnf update 'kernel*', Bodhi, Kernel-Changelog und laufenden Kernel prüfen.
Proxmox VEIm geprüften Material war kein eigenes Proxmox-Security-Advisory sichtbar. Der Host-Kernel zählt trotzdem. LXC teilt den Host-Kernel, KVM-Gäste haben eigene Guest-Kernel.pveversion -v, PVE-Kernel-Changelogs und act_pedit-Status prüfen. Debian-Userland-Status reicht für PVE-Kernel nicht.
Plesk-ServerPlesk selbst ist nicht der Bug. Praktisch relevant sind Plesk-Hosts wegen lokaler Website-Benutzer, PHP-FPM-Pools, Cronjobs, Shell-Zugängen und Kunden-Code.OS-Vendor-Kernel, KernelCare falls vorhanden, Reboot-Status und act_pedit-Mitigation prüfen.
Docker, Kubernetes, LXC, CI-RunnerBesonders relevant, wenn fremder Code läuft. Container teilen den Host-Kernel; CI-Jobs sind lokale Code-Ausführung.Node-/Host-Kernel patchen, User-Namespace- und seccomp/AppArmor/SELinux-Policy prüfen.
Single-Tenant-Server ohne fremde ShellsGeringeres Risiko, aber nicht “egal”. Eine kompromittierte Webanwendung ist lokaler Code.Normal priorisiert patchen. Bei öffentlichem Root-PoC nicht auf den nächsten Quartalstermin schieben.

Patchstände nach Distribution

Die Tabelle ist eine Momentaufnahme. Maßgeblich bleibt der jeweilige Vendor-Tracker und der tatsächlich gebootete Kernel.

Distribution / PlattformStand 08.07.2026
Debian BullseyeKlassischer linux-Zweig bleibt verwundbar, auch Bullseye Security 5.10.259-1. Separater linux-6.1-Zweig in Bullseye Security ist ab 6.1.176-1~deb11u1 gefixt.
Debian BookwormBookworm Security ist ab 6.1.176-1 gefixt. Die normale Bookworm-Zeile 6.1.170-3 steht weiter auf vulnerable.
Debian TrixieTrixie Security ist laut DSA-6355-1 ab 6.12.94-1 gefixt; der CVE-Tracker zeigt inzwischen 6.12.95-1 als aktuellen fixed Security-Stand. Die normale Trixie-Zeile 6.12.86-1 ist weiter vulnerable markiert.
Debian Forky / SidForky ist ab 7.0.13-1 gefixt; Sid steht mit 7.1.3-1 auf fixed.
Ubuntu 22.04 / 24.04 / 25.10 / 26.04Ubuntu-CVE-Seite: High, zuletzt am 05.07. aktualisiert, sichtbare unterstützte Kernel-Tracks weiter vulnerable. Kernel-Flavour und Ubuntu Security Notices prüfen.
RHEL 8/9/10Red Hat RHSB-2026-008: Important, Update vom 03.07.; RHEL 8/9/10 mit All fixes released. Typische EL-Fixstände in kompatiblen Distributionen: 4.18.0-553.136.1.el8_10, 5.14.0-687.17.1.el9_8, 6.12.0-211.26.1.el10_2.
AlmaLinux 8kernel-4.18.0-553.136.1.el8_10 oder neuer.
AlmaLinux 9kernel-5.14.0-687.17.1.el9_8 oder neuer.
AlmaLinux 10kernel-6.12.0-211.26.1.el10_2 oder neuer.
Rocky Linux 8RLSA-2026:27353, am 05.07.2026 aktualisiert; kernel-4.18.0-553.136.1.el8_10 oder neuer.
Rocky Linux 9RLSA-2026:27789, am 05.07.2026 aktualisiert; kernel-5.14.0-687.17.1.el9_8 oder neuer.
Rocky Linux 10RLSA-2026:27288, am 05.07.2026 aktualisiert; kernel-6.12.0-211.26.1.el10_2 oder neuer.
CloudLinux 7Laut CloudLinux nicht betroffen.
CloudLinux 7h / 8Betroffen. Zielstände: kernel-4.18.0-553.137.1.lve.el7h bzw. kernel-4.18.0-553.137.1.lve.el8 oder neuer; zum CloudLinux-Stand vom 26.06. zunächst Beta/rolling stable.
CloudLinux 9 / 10Betroffen, nutzen AlmaLinux-Kernelstände: 5.14.0-687.17.1.el9_8 und 6.12.0-211.26.1.el10_2 oder neuer.
CloudLinux for Ubuntu 22.04Betroffen. Canonical-Kernel-Fix steht laut Ubuntu-Seite weiter aus; KernelCare for Ubuntu nennt K20260625_01 als live im Production Feed.
KernelCareLaut CloudLinux seit 02.07. im Main/Production Feed live: CL8 K20260624_18, CL9 K20260626_30, CL10 K20260625_20, CloudLinux for Ubuntu 22.04 K20260625_01. Per kcarectl nachweisen, nicht nur annehmen.
Amazon LinuxAWS-CVE-Seite: Medium. AL2 Kernel-5.4, Kernel-5.10 und Kernel-5.15 Extra sowie AL2023 kernel, kernel6.12 und kernel6.18 stehen auf Pending Fix; AL2 Core ist Not Affected. Konkreten ALAS-Track prüfen.
Oracle Linux 8 / 9 RHCKOracle ELSA-2026-27353 für OL8 und ELSA-2026-27789 für OL9. OL8/OL9-RHCK-Fixstände entsprechen den EL-Versionen 4.18.0-553.136.1.el8_10 und 5.14.0-687.17.1.el9_8.
Oracle Linux UEKOracle führt zusätzliche UEK-Errata: ELSA-2026-50372 für OL10/OL9 UEKR8 mit kernel-uek-6.12.0-204.92.4.2.el10uek bzw. .el9uek, ELSA-2026-50373 für OL8/OL9 UEKR7 mit kernel-uek-5.15.0-322.203.3.2.el8uek bzw. .el9uek und ELSA-2026-50374 für OL7/OL8 UEKR6 mit kernel-uek-5.4.17-2136.357.3.1.el7uek bzw. .el8uek.
SUSE Liberty Linux 8 / 9 / 10Veröffentlichte Pakete ab 4.18.0-553.136.1.el8_10, 5.14.0-687.17.1.el9_8 und 6.12.0-211.26.1.el10_2.
SLES 15 SP7 / SAP 15 SP7SUSE listet veröffentlichte Pakete wie kernel-default >= 6.4.0-150700.53.55.1; gleichzeitig stehen viele Produkt-/Paketzeilen weiter auf In progress, und neuere QA-Zeilen wie 6.4.0-150700.53.66.1 sind sichtbar. Produktgenau prüfen.
SLES 15 SP6-LTSS / SAP 15 SP6Für SP6-LTSS listet SUSE Pakete wie kernel-default >= 6.4.0-150600.23.112.1; die Statustabelle zeigt aber weiterhin mehrere SP6-LTSS- und SAP-SP6-Kernelpakete als In progress. SLES 15 SP6 ohne LTSS ist betroffen.
openSUSE Leap 15.6SUSE führt kernel-default und kernel-source für Leap 15.6 als released. Leap 16.0 bleibt betroffen.
SLES 16.0 / 16.1, openSUSE Leap 16.0, SUSE Linux Micro 6.2SUSE-CVE-Seite führt diese Linien zum geprüften Stand als affected.
SUSE Linux Micro 5.x / Micro 6.0 / Micro 6.1Micro 5.0 bis 5.5 sind laut SUSE-Seite nicht betroffen; Micro 6.0 und 6.1 sind mit veröffentlichten Fixes geführt.
Proxmox VEKein eigener belastbarer PSA-Fixstand im geprüften Material. PVE-Kernel-Changelog und laufenden Host-Kernel prüfen.

Was ist nicht betroffen oder deutlich entschärft?

Nicht betroffen oder praktisch entschärft sind Systeme, bei denen der verwundbare Pfad nicht vorhanden, nicht erreichbar oder bereits gefixt ist. Das muss man belegen.

  • Der laufende Kernel enthält den Upstream-Fix 899ee91156e5 oder einen Vendor-Backport.
  • Ein Livepatch nennt CVE-2026-46331 oder den passenden act_pedit-/net/sched-Fix für exakt den laufenden Kernel.
  • act_pedit ist weder geladen noch autoloadbar.
  • Der Kernel enthält CONFIG_NET_ACT_PEDIT nicht oder das Modul ist im laufenden Kernel nicht vorhanden.
  • Unprivileged user namespaces sind so eingeschränkt, dass ein normaler Benutzer den bekannten Namespace-CAP_NET_ADMIN-Pfad nicht bekommt.
  • CloudLinux 7 ist laut CloudLinux nicht betroffen.
  • KVM-Gäste teilen den Host-Kernel nicht. Sie müssen trotzdem als eigene Linux-Systeme gepatcht werden.

Wichtig: “Das Modul ist gerade nicht geladen” reicht nicht. Wenn act_pedit durch tc oder Modul-Autoloading nachgeladen werden kann, ist der Host nicht sauber mitigiert. Deshalb ist eine install act_pedit /bin/false-Regel härter als eine reine blacklist-Zeile.

Schnelle Prüfung auf einem Host

Zuerst brauchst du den laufenden Kernel:

uname -r
uname -a

Dann prüfst du die installierten Kernelpakete. Auf Debian, Ubuntu und Proxmox:

dpkg -l 'linux-image*' 'linux-modules*' 'proxmox-kernel*' 'pve-kernel*' 2>/dev/null | awk '/^ii/ {print $2, $3}'

Auf RHEL-, Alma-, Rocky-, CloudLinux-, Oracle- und Fedora-nahen Systemen:

rpm -q kernel kernel-core kernel-modules kernel-modules-extra kernel-uek 2>/dev/null
uname -r

Auf SUSE und openSUSE:

zypper se -si 'kernel*'
uname -r

Prüfen, ob act_pedit aktuell geladen ist:

grep -E '^act_pedit ' /proc/modules || echo "act_pedit aktuell nicht geladen"

Prüfen, ob das Modul im laufenden Kernel vorhanden ist:

find "/lib/modules/$(uname -r)" -type f -name 'act_pedit.ko*' -print

Prüfen, was modprobe tun würde:

modprobe -n -v act_pedit

Wenn dort install act_pedit /bin/false oder eine vergleichbare Vendor-Regel erscheint, ist eine harte Modul-Blockade aktiv. Wenn dort insmod .../act_pedit.ko erscheint, ist das Modul weiterhin ladbar.

Falls die Kernel-Konfiguration verfügbar ist:

grep -E 'CONFIG_NET_SCHED|CONFIG_NET_CLS_ACT|CONFIG_NET_ACT_PEDIT|CONFIG_USER_NS' "/boot/config-$(uname -r)" 2>/dev/null || true
zgrep -E 'CONFIG_NET_SCHED|CONFIG_NET_CLS_ACT|CONFIG_NET_ACT_PEDIT|CONFIG_USER_NS' /proc/config.gz 2>/dev/null || true

Prüfen, ob auf dem Host tatsächlich pedit-Regeln genutzt werden:

for dev in /sys/class/net/*; do
  iface=${dev##*/}
  tc filter show dev "$iface" ingress 2>/dev/null | grep -i pedit && echo "pedit ingress auf $iface"
  tc filter show dev "$iface" egress 2>/dev/null | grep -i pedit && echo "pedit egress auf $iface"
done

Für den bekannten Angriffspfad sind unprivileged user namespaces wichtig:

sysctl user.max_user_namespaces 2>/dev/null
sysctl kernel.unprivileged_userns_clone 2>/dev/null
sysctl kernel.apparmor_restrict_unprivileged_userns 2>/dev/null
sysctl kernel.apparmor_restrict_unprivileged_unconfined 2>/dev/null

Das ist kein vollständiger Vulnerability-Scanner. Es beantwortet aber die ersten Betriebsfragen:

  1. Welcher Kernel läuft wirklich?
  2. Ist act_pedit vorhanden, geladen oder ladbar?
  3. Gibt es legitime tc pedit-Regeln?
  4. Können unprivilegierte Benutzer User-Namespaces nutzen?
  5. Gibt es lokale Workloads, denen du nicht vollständig vertraust?

Updates einspielen

Die saubere Lösung ist ein Kernel-Update aus den Repositories deiner Distribution. Danach muss der Host in den gefixten Kernel booten oder du musst einen passenden Livepatch nachweisen.

Debian, Ubuntu und Proxmox:

sudo apt update
sudo apt full-upgrade
sudo reboot
uname -r

Auf Proxmox zusätzlich:

pveversion -v
dpkg -l 'proxmox-kernel*' 'pve-kernel*' | awk '/^ii/ {print $2, $3}'
apt-cache policy proxmox-kernel-6.8 proxmox-kernel-6.14 proxmox-kernel-6.17 proxmox-kernel-7.0 2>/dev/null
apt changelog proxmox-kernel-6.8 proxmox-kernel-6.14 proxmox-kernel-6.17 proxmox-kernel-7.0 2>/dev/null | grep -Ei 'CVE-2026-46331|pedit|act_pedit|net/sched|899ee911' || true
proxmox-boot-tool status 2>/dev/null || true

RHEL, AlmaLinux, Rocky Linux, CloudLinux, Oracle Linux und Fedora:

sudo dnf clean metadata
sudo dnf update 'kernel*'
sudo reboot
uname -r

Bei älteren EL-Systemen kann noch yum statt dnf relevant sein.

SUSE und openSUSE:

sudo zypper refresh
sudo zypper patch
sudo reboot
uname -r

Bei Kernel-Livepatching zählt nicht uname -r allein. Der Release-String bleibt normalerweise gleich. Du brauchst den Nachweis aus dem Livepatch-Tool:

canonical-livepatch status --verbose 2>/dev/null || true
kpatch list 2>/dev/null || true
kcarectl --patch-info 2>/dev/null | grep -Ei 'CVE-2026-46331|pedit|act_pedit|net/sched' || true
uptrack-show --available 2>/dev/null || true

Auf RHEL-, Alma-, Rocky-, CloudLinux- und Fedora-nahen Systemen hilft nach Updates zusätzlich:

needs-restarting -r 2>/dev/null || true

Auf Debian und Ubuntu:

needrestart -r l 2>/dev/null || true
checkrestart 2>/dev/null || true

Das ersetzt nicht den Kernelvergleich. Es fängt aber typische Fälle ab, in denen ein Kernelpaket installiert wurde und der Host trotzdem noch mit dem alten Kernel läuft.

Temporäre Mitigation

Wenn ein Kernel-Fix noch nicht verfügbar ist oder ein sofortiger Reboot nicht geht, gibt es zwei sinnvolle Zwischenlösungen. Beide haben Nebenwirkungen.

Option 1: act_pedit blockieren

Vorher solltest du prüfen, ob der Host Traffic-Control-Regeln mit pedit nutzt:

for dev in /sys/class/net/*; do
  iface=${dev##*/}
  tc filter show dev "$iface" ingress 2>/dev/null | grep -i pedit && echo "pedit ingress auf $iface"
  tc filter show dev "$iface" egress 2>/dev/null | grep -i pedit && echo "pedit egress auf $iface"
done

Wenn pedit nicht gebraucht wird, ist eine harte Blockade:

printf '%s\n' 'install act_pedit /bin/false' | sudo tee /etc/modprobe.d/disable-act-pedit.conf

if grep -q '^act_pedit ' /proc/modules; then
  sudo rmmod act_pedit || echo "WARNUNG: act_pedit konnte nicht entladen werden"
fi

modprobe -n -v act_pedit

Wenn die Mitigation über einen Reboot hinweg sicher greifen soll, aktualisiere je nach Distribution auch das initramfs. In vielen Server-Setups wird act_pedit nicht früh im Boot geladen, aber bei Notfall-Mitigationen ist der zusätzliche Schritt sauberer als eine halbe Blockade.

Debian und Ubuntu:

sudo update-initramfs -u -k all

RHEL-, Alma-, Rocky-, CloudLinux-, Oracle- und Fedora-nahe Systeme:

sudo dracut -f

SUSE:

sudo dracut -f

Zurücknehmen nach aktivem Kernel-Fix:

sudo rm /etc/modprobe.d/disable-act-pedit.conf

if command -v update-initramfs >/dev/null; then
  sudo update-initramfs -u -k all
fi

if command -v dracut >/dev/null; then
  sudo dracut -f
fi

Danach rebooten oder nach Vendor-Anweisung sicherstellen, dass die alte Blockade nicht aus einem initramfs oder Konfigurationsmanagement zurückkommt.

Option 2: unprivilegierte User-Namespaces einschränken

Der bekannte Exploit braucht den Weg über unprivileged user namespaces, um in einer eigenen Network-Namespace-Welt CAP_NET_ADMIN zu bekommen. Wenn du diesen Weg schließt, fällt der bekannte Angriffspfad weg. Das kann aber Rootless Docker/Podman, Build-Sandboxes, Browser-Sandboxing, Flatpak und Entwickler-Workflows brechen.

Auf EL-nahen Systemen ist die harte Variante:

sudo sysctl -w user.max_user_namespaces=0
printf '%s\n' 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf
sudo sysctl --system

Auf Debian und Ubuntu ist häufig zusätzlich oder alternativ relevant:

sudo sysctl -w kernel.unprivileged_userns_clone=0
printf '%s\n' 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf
sudo sysctl --system

Auf Ubuntu-Systemen mit AppArmor-Härtung solltest du außerdem die beiden AppArmor-Userns-Sysctls prüfen:

sysctl kernel.apparmor_restrict_unprivileged_userns 2>/dev/null
sysctl kernel.apparmor_restrict_unprivileged_unconfined 2>/dev/null

Eine temporäre User-Namespace-Mitigation solltest du dokumentieren und später bewusst zurücknehmen, wenn sie nicht Teil der normalen Härtung sein soll. Sonst suchst du Wochen später nach kaputten Rootless-Containern und weißt nicht mehr, warum.

Was beim Patchen gern schiefgeht

Der erste Fehler ist ein installiertes Kernelpaket ohne Reboot. Dann liegt der Fix auf der Platte, aber der alte Kernel läuft weiter.

Prüfe nach dem Wartungsfenster immer:

uname -r

und vergleiche den laufenden Kernel mit dem installierten Paketstand und dem Vendor-Tracker.

Der zweite Fehler ist, pedit COW mit Dirty Frag oder Fragnesia gleichzusetzen. Die Fehlerklasse ist ähnlich, aber der angreifbare Kernelpfad ist ein anderer. esp4, esp6, espintcp und rxrpc zu blockieren hilft hier nicht. Für pedit COW geht es um act_pedit und den User-Namespace-Weg.

Der dritte Fehler ist eine blinde act_pedit-Blockade auf Systemen, die Traffic-Control-Regeln zur Paketbearbeitung verwenden. Das ist auf typischen Webhosting-Servern selten, aber bei Routern, DDoS-/QoS-Setups, Appliances und speziellen Container-Netzwerken nicht ausgeschlossen.

Der vierte Fehler ist “Container aktualisiert, Host vergessen”. Docker-, Kubernetes- und LXC-Container bringen keinen eigenen Kernel mit. Der Host entscheidet.

Der fünfte Fehler ist, User-Namespaces ohne Nebenwirkungsprüfung abzuschalten. Für gehärtete Hosting-Hosts kann das sinnvoll sein. Für Entwickler-Hosts, Rootless Container oder CI-Runner kann es produktive Workloads brechen.

Der sechste Fehler ist fehlende Reihenfolge im Cluster. Kubernetes-Nodes werden gedraint, Proxmox-HA-Workloads migriert oder bewusst gestoppt, CI-Runner aus der Queue genommen. Ein Kernelupdate ist kein normales Userland-Paketupdate.

Page Cache nach Test oder Verdacht

Der öffentliche PoC manipuliert die gecachte Kopie von /bin/su. Wenn du den PoC in einem isolierten Lab-System getestet hast, solltest du danach mindestens den Page Cache leeren oder den Host rebooten.

Auf einem Lab-System:

sync
echo 3 | sudo tee /proc/sys/vm/drop_caches >/dev/null

Auf einem produktiven System mit Verdacht auf echte Ausnutzung reicht das nicht. Wenn jemand über pedit COW Root bekommen hat, kann er danach persistente Änderungen vorgenommen, Logs manipuliert oder Secrets gelesen haben. Dann geht es nicht mehr nur um die kontaminierte Page-Cache-Seite. Dann gehören Isolierung, Log- und EDR-Prüfung, Secret-Rotation und je nach System ein sauberer Rebuild auf die Liste.

Datei-Hashes allein sind hier nur begrenzt hilfreich. Die Datei auf der Platte kann sauber sein, während die gelesene RAM-Kopie manipuliert war.

Einordnung für Plesk, Proxmox und Hosting

Für Plesk-Server ist pedit COW relevant, weil Plesk-Hosts oft mehrere lokale Benutzer, PHP-FPM-Pools, Cronjobs, Deployment-Scripte, Backups und Kunden-Code kombinieren. Plesk patcht nicht den Kernel. Entscheidend ist das darunterliegende Betriebssystem, KernelCare falls vorhanden und der Reboot-Nachweis.

Bei Proxmox ist die Trennung wichtig:

  • Proxmox-Host: Der Host-Kernel muss bewertet werden. Admin-Shells, Hooks, Backup-Scripte und Automatisierung laufen nahe am Host.
  • LXC-Container: LXC teilt den Host-Kernel. Ein verwundbarer Host-Kernel ist deshalb direkt relevant.
  • KVM-VMs: KVM-Gäste haben eigene Kernel. Der Gast muss separat gepatcht werden. Ein Exploit im Gast ist nicht automatisch ein Exploit im Host.
  • Cluster: Reboots brauchen Reihenfolge. Dokumentiere pro Node, welcher Kernel läuft und ob eine Mitigation aktiv ist.

Für Hoster, Agenturen und MSPs ist die Priorisierung recht klar: Systeme mit fremdem oder weniger vertrauenswürdigem Code zuerst. Dazu gehören Shared Hosting, Build-Server, GitLab Runner, Kubernetes-Nodes, Docker-Hosts mit Kundenworkloads, Plesk-Server und Proxmox-Hosts mit LXC-Containern.

Wie wir damit umgehen würden

Bei einem produktiven Kunden-Setup wäre die Reihenfolge pragmatisch:

  1. Hostliste aus Inventar, Monitoring, Proxmox, Cloud und Plesk ziehen.
  2. Systeme nach Risiko sortieren: Shared Hosting, Container, CI, Shell-Zugänge, Multi-Tenant zuerst.
  3. Pro Host laufenden Kernel, installierte Kernelpakete, act_pedit-Status und User-Namespace-Policy prüfen.
  4. Vendor-Fixes gegen Debian/Ubuntu/Red Hat/SUSE/Alma/Rocky/CloudLinux/Oracle/AWS/Proxmox-Paketstand abgleichen.
  5. Wenn kein Fix oder kein sofortiger Reboot möglich ist: act_pedit blockieren oder User-Namespaces einschränken, aber Nebenwirkungen dokumentieren.
  6. Reboot- oder Livepatch-Nachweis dokumentieren.
  7. Nachkontrolle: laufender Kernel, Modulstatus, Monitoring und offene Hosts.
  8. Bei Verdacht auf Ausnutzung nicht nur Cache leeren, sondern Incident-Pfad starten.

Wenn du gerade sowieso wegen Linux-Kernel-Lücken patchst, prüfe den kompletten Kernel-Advisory-Stand deines Vendors. Die letzten Wochen haben mit Copy Fail, Dirty Frag, Fragnesia und ssh-keysign-pwn gezeigt, dass ein Reboot für nur eine CVE oft zu kurz gedacht ist.

Wenn du nicht sicher bist, ob deine Server wirklich gefixt sind, ist ein kurzer Security- und Kernel-Check sinnvoller als ein hektischer Reboot ohne Nachkontrolle. Gerade bei Plesk-, Proxmox-, Container- und CI-Umgebungen ist die Frage nicht nur “Update ja/nein”, sondern “welcher Host kann wann rebooten, welche Workloads brechen durch die Mitigation, und wie belegen wir danach den Zustand?”

Update-Log

  • 2026-05-31: Der Upstream-Patch net/sched: fix pedit partial COW leading to page cache corruption wurde erstellt.
  • 2026-06-04: Der Fix wurde von Jakub Kicinski in den Kernel-Tree übernommen.
  • 2026-06-16: CVE-2026-46331 wurde in mehreren Vendor-Trackern sichtbar; Ubuntu, AWS und Oracle führen dieses Datum als Public/Release Date.
  • 2026-06-17: Der öffentliche PoC packet_edit_meme wurde laut CloudLinux veröffentlicht und demonstriert unprivileged local user to root.
  • 2026-06-19: Red Hat veröffentlichte RHSB-2026-008 zu act_pedit/Traffic-Control Privilege Escalation.
  • 2026-06-22 bis 2026-06-25: AlmaLinux, Rocky Linux, Oracle Linux und SUSE Liberty Linux veröffentlichten EL-nahe Kernelpakete für 8/9/10-Linien.
  • 2026-06-26: CloudLinux veröffentlichte die pedit-COW-Mitigation und Kernel-Update-Hinweise; The Hacker News griff das Thema öffentlich auf.
  • 2026-06-27: Artikel angelegt. Debian-, Ubuntu-, Red-Hat-, Alma-, Rocky-, CloudLinux-, AWS-, Oracle- und SUSE-Stände gegen öffentlich sichtbare Tracker geprüft.
  • 2026-06-27: Quellenabgleich ergänzt: CVEProject-Stable-Bereiche vor 5.18 und produktgenaue SUSE-Stati in die Patchstand-Tabelle aufgenommen.
  • 2026-06-29: Tracker erneut geprüft. Ubuntu, Debian, CloudLinux, Red Hat, Oracle und SUSE zeigen keine neue pauschale Entwarnung; Rocky-RLSA-Seiten sind auf 29.06. aktualisiert, die Zielkernel bleiben gleich. Amazon-Linux-Trackliste präzisiert, inklusive AL2 Kernel-5.4/5.10/5.15 Extra und AL2023 kernel/kernel6.12/kernel6.18.
  • 2026-06-30: Ubuntu-CVE-Seite und CVEProject-Record wurden aktualisiert. Für Ubuntu waren weiter keine Fixed-Zeilen bei den sichtbaren unterstützten Kernel-Tracks erkennbar; die im Artikel genannten CVEProject-Stable-Bereiche blieben für die Bewertung unverändert.
  • 2026-07-01: Alle Artikelquellen erneut geprüft. Debian Bullseye/Bookworm bleiben im Security Tracker verwundbar; Ubuntu bleibt trotz Tracker-Update auf vulnerable. Rocky-RLSA-Seiten sind auf 01.07. aktualisiert, die Zielkernel bleiben unverändert. SUSE-SP7-Paketstände präzisiert.
  • 2026-07-02: CloudLinux ergänzte KernelCare-Livepatches als live im Main/Production Feed, inklusive Patch-IDs für CL8, CL9, CL10 und CloudLinux for Ubuntu 22.04.
  • 2026-07-03: Red Hat aktualisierte RHSB-2026-008; RHEL 8, 9 und 10 stehen dort nun auf All fixes released.
  • 2026-07-04: CVEProject-Record erneut aktualisiert; die für den Artikel relevanten Upstream-/Stable-Bereiche und der zentrale Fix-Commit bleiben gleich.
  • 2026-07-02 bis 2026-07-04: Oracle ergänzte UEK-Errata für CVE-2026-46331: ELSA-2026-50372 für OL9/OL10 UEKR8, ELSA-2026-50373 für OL8/OL9 UEKR7 und ELSA-2026-50374 für OL7/OL8 UEKR6.
  • 2026-07-05: Ubuntu-CVE-Seite erneut aktualisiert, aber sichtbare unterstützte Kernel-Tracks bleiben vulnerable. Rocky-RLSA-Seiten wurden auf 05.07. aktualisiert, Zielkernel unverändert.
  • 2026-07-06: Debian-Tracker erneut geprüft: Bookworm Security ist gefixt, Bullseye linux-6.1 ist gefixt, klassisches Bullseye-linux bleibt verwundbar, Trixie Security/Forky/Sid aktualisiert. SUSE-Stati erneut getrennt: SLES 15 SP7 teils In progress, SLES 15 SP6-LTSS/openSUSE Leap 15.6 mit veröffentlichten Paketlisten.
  • 2026-07-07: CVEProject-Record aktualisiert; die Upstream-/Stable-Fixschwellen 6.12.94, 6.18.36, 7.0.13 und 7.1 sind jetzt explizit sichtbar. CloudLinux änderte die Blogseite, die KernelCare-Patch-IDs bleiben unverändert.
  • 2026-07-08: Alle Quellen erneut geprüft. Debian, Ubuntu, Red Hat, AWS, Alma/Rocky, Fedora/Bodhi und Proxmox ohne neue pedit-COW-Entwarnung; SUSE-Status für SP6-LTSS/SP7 präzisiert.

Quellen