Security 27.06.2026 Aktualisiert: 27.06.2026

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.

Stand: 27.06.2026, 23:20 Uhr CEST. pedit COW, CVE-2026-46331, ist eine lokale Linux-Kernel-Lücke mit öffentlichem Root-Exploit. Debian hat Trixie Security und Sid gefixt, aber Bullseye und Bookworm standen im Debian Tracker noch auf verwundbar. Ubuntu markiert die unterstützten Kernel-Tracks als verwundbar. RHEL-nahe Distributionen haben inzwischen konkrete Kernelstände, CloudLinux hat eigene Sonderpfade. 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:

Der Angreifer hat lokale Code-Ausführung als normaler Benutzer.
Er erstellt User- und Network-Namespaces.
In dieser Namespace-Welt hat er CAP_NET_ADMIN.
Damit kann er Traffic-Control-Actions konfigurieren.
act_pedit bearbeitet ein Paket mit einem zur Laufzeit berechneten Offset.
Die alte Kernel-Logik hat nicht den gesamten späteren Schreibbereich privatisiert.
Der Write erreicht eine gemeinsam genutzte Page-Cache-Seite.
Eine gecachte Kopie eines SUID-root-Binaries wird im RAM manipuliert.
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. 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.

Umgebung	Einschätzung	Worauf prüfen
Debian	Debian Security Tracker: Trixie Security ist ab `6.12.94-1` gefixt, Sid ab `7.0.13-1`. Bullseye, Bullseye Security, Bookworm, Bookworm Security, Trixie ohne Security und Forky standen zum geprüften Stand noch auf vulnerable.	Nicht nur Debian-Version prüfen. Entscheidend sind `linux`-Paketstand, Security-Repo und laufender Kernel nach Reboot.
Ubuntu	Canonical bewertet CVE-2026-46331 als High und markiert unterstützte Kernel-Tracks, sichtbar unter anderem 22.04, 24.04, 25.10 und 26.04, 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 / OpenShift	Red Hat führt RHSB-2026-008 als Important/Ongoing. Betroffen sind RHEL 8, 9, 10, RHEL for NVIDIA und Produkte auf RHEL-Kernelbasis. OpenShift ist 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.
AlmaLinux	AlmaLinux 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 Linux	Rocky hat RLSA-2026:27353, RLSA-2026:27789 und RLSA-2026:27288 veröffentlicht.	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.
CloudLinux	CL7 ist laut CloudLinux nicht betroffen. CL7h, CL8, CL9, CL10 und CloudLinux for Ubuntu 22.04 sind betroffen.	CL7h/CL8: CloudLinux-Zielstände `kernel-4.18.0-553.137.1.lve...` oder neuer. CL9/CL10 folgen AlmaLinux-Zielständen. KernelCare separat nachweisen.
Amazon Linux	AWS führt CVE-2026-46331 mit Medium Severity. Die Amazon-Linux-CVE-Seite zeigte zum geprüften Stand sichtbare Kerneltracks, darunter Amazon Linux 2 Kernel-5.10 und Kernel-5.15 Extra, als `Pending Fix`.	ALAS-Seite und konkrete Kerneltracks prüfen. Nicht aus RHEL-, Alma- oder Rocky-Fixständen ableiten.
Oracle Linux	Oracle führt CVE-2026-46331 als Important und nennt ELSA-2026-27353 für Oracle Linux 8 sowie ELSA-2026-27789 für Oracle Linux 9.	RHCK/UEK getrennt prüfen. `uname -r`, `rpm -q kernel kernel-uek` und Oracle-CVE-/ELSA-Seiten abgleichen.
SUSE / openSUSE / SUSE Liberty Linux	SUSE bewertet das Thema als Important. Die CVE-Seite hat inzwischen produktgenaue Stati: SUSE Liberty Linux 8/9/10, SLES 15 SP7, SLES 15 SP6-LTSS, openSUSE Leap 15.6 und SUSE Linux Micro 6.0/6.1 sind mit veröffentlichten Fixes geführt; SLES 16.0/16.1, openSUSE Leap 16.0 und Micro 6.2 stehen weiter auf affected. Mehrere Micro-5.x- und ältere SLES-Linien sind als not affected geführt.	Produktgenaue SUSE-CVE-Seite prüfen. Liberty-Linux-EL-Fixstände nicht blind auf SLES, Micro oder openSUSE übertragen.
Fedora / Rolling Releases	Der 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 VE	Im 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-Server	Plesk 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-Runner	Besonders 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 Shells	Geringeres 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 / Plattform	Stand 27.06.2026
Debian Bullseye	`linux` in Bullseye und Bullseye Security standen im Debian Security Tracker noch auf vulnerable.
Debian Bookworm	Bookworm und Bookworm Security standen im Tracker noch auf vulnerable.
Debian Trixie	Trixie Security ab `6.12.94-1` gefixt. Die normale Trixie-Zeile `6.12.86-1` war noch vulnerable markiert.
Debian Forky / Sid	Forky stand noch auf vulnerable; Sid ist ab `7.0.13-1` gefixt.
Ubuntu 22.04 / 24.04 / 25.10 / 26.04	Ubuntu-CVE-Seite: High, visible supported tracks vulnerable. Kernel-Flavour und Ubuntu Security Notices prüfen.
RHEL 8/9/10	Red Hat RHSB-2026-008: Important, Ongoing, viele Fixes verfügbar, weitere folgen. 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 8	`kernel-4.18.0-553.136.1.el8_10` oder neuer.
AlmaLinux 9	`kernel-5.14.0-687.17.1.el9_8` oder neuer.
AlmaLinux 10	`kernel-6.12.0-211.26.1.el10_2` oder neuer.
Rocky Linux 8	RLSA-2026:27353, `kernel-4.18.0-553.136.1.el8_10` oder neuer.
Rocky Linux 9	RLSA-2026:27789, `kernel-5.14.0-687.17.1.el9_8` oder neuer.
Rocky Linux 10	RLSA-2026:27288, `kernel-6.12.0-211.26.1.el10_2` oder neuer.
CloudLinux 7	Laut CloudLinux nicht betroffen.
CloudLinux 7h / 8	Betroffen. 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 / 10	Betroffen, 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.04	Betroffen, hängt am Ubuntu-Kernel-Fix und optional KernelCare-Livepatch.
KernelCare	CloudLinux nannte KernelCare-Livepatches zum Stand 26.06. als in Build/Test. Per `kcarectl` nachweisen, nicht nur annehmen.
Amazon Linux	AWS-CVE-Seite: Medium, sichtbare Kerneltracks mit `Pending Fix`. Konkreten ALAS-Track prüfen.
Oracle Linux 8 / 9	Oracle 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`.
SUSE Liberty Linux 8 / 9 / 10	Verö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 / SLES 15 SP6-LTSS / openSUSE Leap 15.6	SUSE-CVE-Seite führt diese Linien mit veröffentlichten Fixes. SLES 15 SP6 ohne LTSS ist separat als affected markiert.
SLES 16.0 / 16.1, openSUSE Leap 16.0, SUSE Linux Micro 6.2	SUSE-CVE-Seite führt diese Linien zum geprüften Stand als affected.
SUSE Linux Micro 5.x / Micro 6.0 / Micro 6.1	Micro 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 VE	Kein 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:

Welcher Kernel läuft wirklich?
Ist act_pedit vorhanden, geladen oder ladbar?
Gibt es legitime tc pedit-Regeln?
Können unprivilegierte Benutzer User-Namespaces nutzen?
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:

Hostliste aus Inventar, Monitoring, Proxmox, Cloud und Plesk ziehen.
Systeme nach Risiko sortieren: Shared Hosting, Container, CI, Shell-Zugänge, Multi-Tenant zuerst.
Pro Host laufenden Kernel, installierte Kernelpakete, act_pedit-Status und User-Namespace-Policy prüfen.
Vendor-Fixes gegen Debian/Ubuntu/Red Hat/SUSE/Alma/Rocky/CloudLinux/Oracle/AWS/Proxmox-Paketstand abgleichen.
Wenn kein Fix oder kein sofortiger Reboot möglich ist: act_pedit blockieren oder User-Namespaces einschränken, aber Nebenwirkungen dokumentieren.
Reboot- oder Livepatch-Nachweis dokumentieren.
Nachkontrolle: laufender Kernel, Modulstatus, Monitoring und offene Hosts.
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.