Die COW-Sicherheitslücke im Linux-Pedit als Ursache für einen neuen Root-Exploit

Suchen Sie nach Maßnahmen zur Risikominderung? Springen Sie direkt dorthin ↓

Die Kurzfassung

Was: Eine lokale Privilegieneskalation unter Linux namens „pedit COW“ (CVE-2026-46331), bei der es sich um einen Schreibvorgang ohne Bereichsprüfung in der Verkehrssteuerungsaktion „act_pedit“ des Kernels handelt. Die Funktion `tcf_pedit_act()` berechnet ihren „Copy-on-Write“-Bereich einmalig, bevor sie Paket-Header bearbeitet, übersieht dabei den Laufzeit-Offset, den typisierte Schlüssel zur Laufzeit hinzufügen, und schreibt schließlich in eine Seite, die sie nie als privat markiert hat – ein partielles COW, das im gemeinsam genutzten Seiten-Cache landet.

Auswirkung: Ein öffentlicher, vom Autor verifizierter Proof-of-Concept bietet jedem lokalen Benutzer ohne Sonderrechte einen einfachen Weg zu einer Root-Shell auf betroffenen Systemen, auf denen die Aktion „act_pedit“ erreichbar ist und Namespaces für Benutzer ohne Sonderrechte verfügbar sind. Der PoC manipuliert das zwischengespeicherte Image von „setuid-root /bin/su“ und verschafft sich direkt Root-Rechte. Red Hat stuft die Schwachstelle als „Wichtig“ ein.

Status: Es handelt sich um eine N-Tage- und nicht um eine „Same-Day“-Überraschung. Der Fix wurde offen auf der netdev-Mailingliste als routinemäßiger Patch zur Behebung einer Datenbeschädigung entwickelt (Betreff: „net/sched: fix pedit partial COW leading to page cache corruption“), ohne CVE-Nummer und ohne Sicherheitskontext. Der CNA von kernel.org vergab die CVE-Nummer CVE-2026-46331 zum Zeitpunkt der Einbindung am 16. Juni 2026 – Wochen, nachdem die Details zur Ausnutzung bereits öffentlich bekannt waren – und am 17. Juni wurde ein ausnutzbarer PoC veröffentlicht. Mainline und Stable sind behoben; Red Hat und AlmaLinux haben Errata veröffentlicht.

Schweregrad: Lokaler Angriffsvektor, geringe Komplexität, sobald die Voraussetzungen erfüllt sind, keine Benutzerinteraktion, deterministische Seite-Cache-Korruption bis hin zu Root-Rechten sowie funktionierender öffentlicher Exploit-Code. Fehlerklasse: Schreibzugriff außerhalb des zulässigen Bereichs, der zu einer Speicherbeschädigung und einer lokalen Rechteausweitung führt. Der CVSS-Wert stand zum Zeitpunkt der Veröffentlichung noch nicht endgültig fest; die Einstufung „Wichtig“ von Red Hat dient als Maßstab für die erforderlichen Maßnahmen.

Gehen Sie sofort wie folgt vor: Installieren Sie einen vom Hersteller korrigierten Kernel, sofern vorhanden (RHEL 8/9/10, AlmaLinux 8, Debian 13), und starten Sie den Rechner neu. Der „rebootless“-Patch von KernelCare befindet sich noch in der Testphase und wurde noch in keinem Repository veröffentlicht; warten Sie also nicht darauf. Bis Sie den Patch installieren können, verhindern Sie das Laden von `act_pedit`, wenn Sie keine `tc pedit`-Regeln verwenden, und/oder schränken Sie die Namespaces nicht privilegierter Benutzer ein. Befehle und zu beachtende Kompromisse finden Sie weiter unten.

Die Langfassung

CVE-2026-46331 ist ein weiterer Fehler in Linux, der zu einer Beschädigung des Seiten-Caches führt und einen Schreibfehler im Kernel in einen praxistauglichen Pfad von lokal zu Root umwandelt. Er befindet sich im Traffic-Control-Subsystem, genauer gesagt in der Paketbearbeitungsaktion „act_pedit“, die tc verwendet, um Header-Bytes von Paketen während der Übertragung umzuschreiben.

Das Beunruhigende daran ist nicht nur der Fehler selbst, sondern auch die Art und Weise, wie er ans Licht kam.

Der Upstream-Patch wurde öffentlich als Korrektur für eine Datenbeschädigung diskutiert, ohne CVE und ohne offensichtlichen Sicherheitsbezug. Die CVE-Nummer wurde erst später, zum Zeitpunkt der Zusammenführung am 16. Juni, vergeben, und am nächsten Tag folgte ein öffentlicher, ausnutzbarer PoC. Damit ist „pedit COW“ in einer für Verteidiger entscheidenden Hinsicht ein N-Day: Die ausnutzbaren technischen Details waren auf einer öffentlichen Mailingliste sichtbar, bevor die meisten Teams über eine CVE-Nummer, eine Scanner-Regel, einen Herstellerhinweis oder einen damit verbundenen Patch-Prozess verfügten.

Wir haben diesen Fehler nicht im Rahmen unserer eigenen Überwachung entdeckt. Er wurde uns über eine Eskalation eines Kunden gemeldet – er war nie auf oss-security zu finden, und der CNA-Stream des Kernels steht derzeit nicht auf unserer Beobachtungsliste. Diese Lücke ist eine Lehre für sich, was Kernel-Fehler betrifft, bei denen erst behoben und erst später ein CVE vergeben wird, und sie ist einer der Gründe, warum es diesen Beitrag gibt.

Bin ich betroffen?

Ein Host gilt als exponiert, wenn alle folgenden Bedingungen erfüllt sind:

• Der Kernel enthält den anfälligen act_pedit-Codepfad.
• Das Modul „act_pedit“ ist geladen oder kann bei Bedarf automatisch geladen werden.
• Namensräume für nicht privilegierte Benutzer sind aktiviert, wodurch ein Angreifer die namensraumlokale Berechtigung CAP_NET_ADMIN erhält, die der Exploit benötigt.
• Ein nicht vertrauenswürdiger oder teilweise vertrauenswürdiger lokaler Benutzer kann auf dem Rechner Code ausführen.

act_pedit wird automatisch geladen, sobald eine „pedit tc“-Aktion konfiguriert wird; daher ist ein leerer lsmod-Eintrag nicht unbedingt ein Entwarnungssignal, wie es zunächst den Anschein hat. Überprüfen Sie alle drei Bedingungen:

# Is the module loaded right now?
lsmod | grep -w act_pedit

# Can it be loaded on demand?
modinfo act_pedit 2>/dev/null | head -n 1

# Are unprivileged user namespaces available?
sysctl user.max_user_namespaces kernel.unprivileged_userns_clone 2>/dev/null

Sie können außerdem überprüfen, ob Sie die Aktion tatsächlich nutzen: Der Befehl „tc actions list action pedit“ liefert auf Hosts, auf denen derzeit keine pedit-Regeln ausgeführt werden, keine Ergebnisse. Eine leere Ausgabe bedeutet jedoch nicht, dass Sie sicher sind – ein Angreifer, der eine Regel aus einem Namespace heraus einfügen kann, gelangt dennoch in den Codepfad –, aber sie gibt Aufschluss darüber, ob die empfohlene Abhilfemaßnahme mit der Modul-Blacklist sicher angewendet werden kann.

Unter RHEL und Debian ist „unprivileged_userns“ standardmäßig aktiviert. Unter Ubuntu wird dies durch die Kernel-Einstellungen `apparmor_restrict_unprivileged_userns` bzw. `_unconfined` eingeschränkt, doch handelt es sich dabei um eine Sicherheitsmaßnahme und nicht um eine Kernel-Korrektur – der PoC umgeht diese Einschränkung unter 24.04 mithilfe eines `aa-exec`-Tricks. Ubuntu 26.04 meldet aus demselben AppArmor-Grund „FAIL“ beim PoC, während der zugrunde liegende Kernel weiterhin anfällig bleibt.

Was ist pedit COW?

„pedit“ ist die Abkürzung für „Packet Editor“ – eine Maßnahme zur Verkehrssteuerung, mit der Administratoren Felder in Paket-Headern umschreiben können, während die Pakete konfigurierte tc-Filter und -Aktionen durchlaufen. Die anfällige Funktion ist „tcf_pedit_act()“ in der Datei „net/sched/act_pedit.c“.

Es gehört zur gleichen Familie wie „Dirty Pipe“, „Copy Fail“ und „Dirty Frag“: Eine Kernel-Routine schreibt in eine Seite, über die sie nicht die ausschließliche Kontrolle besitzt, und der Schreibvorgang landet in einem Page-Cache-Eintrag, der eine Datei auf der Festplatte abbildet. Neu ist hier der Auslösepunkt. Anstelle eines Krypto-Fast-Paths oder eines Zero-Copy-Entschlüsselungspfads ist der Auslöser eine Paketbearbeitungsaktion, die ein Prozess ohne Sonderrechte von innerhalb eines Benutzer-Namespace aus konfigurieren kann.

Grob gesagt entsteht der Fehler dadurch, dass der Bereich der beschreibbaren Pakete zu früh berechnet wird. Bevor Paketdaten geändert werden, ruft der Kernel die Funktion `skb_ensure_writable()` auf, um die Zielbytes als privat zu kennzeichnen. Die Funktion `tcf_pedit_act()` berechnete diesen Bereich einmalig vor der Schleife über die Bearbeitungsschlüssel unter Verwendung eines vorab berechneten Hinweises namens `tcfp_off_max_hint`. Der Hinweis berücksichtigte jedoch nicht den Laufzeit-Header-Offset, den typisierte Schlüssel hinzufügen – diese Schlüssel berechnen ihre Offsets relativ zu den L2-/L3-/L4-Headern zur Laufzeit, sodass der tatsächliche Schreiboffset erst bekannt ist, wenn die Schleife läuft. Ein Teil des Zielbereichs wird daher nie als privat markiert. Dies stellt eine teilweise „Copy-on-Write“-Verarbeitung dar, und das Schreiben in den nicht COW-geschützten Bereich ist ein Schreibvorgang außerhalb des zulässigen Bereichs, der sich über mehrere Seiten erstreckt.

Da das SKB auf Zero-Copy-Seiten verweisen kann, die über `sendfile` geladen wurden, kann dieser Schreibvorgang außerhalb des zulässigen Bereichs in den gemeinsam genutzten Seiten-Cache gelangen, der eine echte Datei abdeckt. Der Kernel geht davon aus, dass er den Paketspeicher so gesichert hat, dass er geändert werden kann; tatsächlich reicht der spätere Schreibvorgang jedoch über den Bereich hinaus, den er tatsächlich privatisiert hat.

Wie der Exploit tatsächlich funktioniert

Der öffentliche PoC (sgkdev/packet_edit_meme) verknüpft vier gewöhnliche Komponenten miteinander – die Aktion „act_pedit“, Socket-Puffer, die auf Zero-Copy-Seiten verweisen können, nicht privilegierte Benutzernamensräume und den Seitencache – und benötigt weder Heap-Shaping noch ein Race-Fenster.

1. Namespace und Berechtigung. Ausgehend von einem Namespace eines Benutzers ohne Sonderrechte erlangt der Angreifer die namespace-lokale Berechtigung CAP_NET_ADMIN – dies reicht aus, um Maßnahmen zur Verkehrssteuerung innerhalb des von ihm kontrollierten Namespaces zu konfigurieren.
2. Traffic-Control-Bindung. Sie konfigurieren eine „pedit“-Aktion mit typisierten Schlüsseln, deren Laufzeit-Offset außerhalb des Bereichs liegt, den tcf_pedit_act() als beschreibbar festgelegt hat, wodurch der partielle COW-Schreibvorgang ausgelöst wird.
3. Page-Cache-Ausnutzung. Durch die Einspeisung von Zero-Copy-Dateiverweisen in den Netzwerkstack zielen sie darauf ab, einen Schreibzugriff außerhalb des zulässigen Bereichs im zwischengespeicherten ELF-Image von setuid-root /bin/su auszulösen.
4. Nutzlast. Sie überschreiben den zwischengespeicherten Einstiegspunkt mit Shellcode, der den Befehlen setgid(0), setuid(0) und execve(„/bin/sh“) entspricht.
5. Root. Sie verlassen den Namensraum und führen „su“ aus. Der gemeinsam genutzte Seiten-Cache stellt das manipulierte Image bereit, und der Shellcode wird als Root ausgeführt.

Die Binärdatei auf der Festplatte ändert sich nie. Die Beschädigung besteht ausschließlich im Seiten-Cache, weshalb Datei-Hashing und Festplattenforensik keine Auffälligkeiten zeigen können, obwohl bereits eine Root-Shell geöffnet ist. Die einzige entscheidende Voraussetzung sind nicht privilegierte Benutzernamensräume mit CAP_NET_ADMIN – diese sind unter RHEL und Debian standardmäßig geöffnet, unter Ubuntu hingegen eingeschränkt.

Was sich durch den Upstream-Fix ändert

Der zusammengeführte Fix (Betreff: „net/sched: act_pedit: Erweiterung des beschreibbaren SKB-Bereichs pro Schlüssel“) strukturiert den COW-Pfad so um, dass der beschreibbare Bereich dem tatsächlichen Offset folgt:

• Dadurch wird `skb_ensure_writable()` in die Schleife für die einzelnen Schlüssel verschoben, wo der tatsächliche Schreiboffset bekannt ist.
• Es fügt eine Überlaufprüfung für die Offset-Arithmetik hinzu und schützt die Funktion `offset_valid()` vor `INT_MIN`, wo die Negation undefiniert ist.
• Bei negativen Offsets – man denke beispielsweise an die Bearbeitung von Ethernet-Headern beim Eingang – wird stattdessen skb_cow() verwendet, um den Headroom nach dem COW-Prinzip zu bearbeiten.
• Es linearisiert SKBs, die gemeinsam genutzte Fragmente enthalten, im Vorfeld, sodass eine Zero-Copy-Seite nicht unbemerkt beschädigt werden kann.

Es handelt sich um eine in sich geschlossene Änderung an einer Funktion. Der „rebootless“-Patch von KernelCare ist eine originalgetreue Portierung dieses Upstream-Fixes und kein konservatives kpatch-Äquivalent: Er baut den COW-Pfad innerhalb von `tcf_pedit_act()` mit derselben Logik für `skb_ensure_writable()` und `skb_cow()` pro Schlüssel sowie den gleichen Offset-Prüfungen neu auf.

Warum dieser Fehler leicht zu übersehen war

„pedit-cow“ wurde den Entwicklern nie als benannter Notfall gemeldet. Es sah aus wie eine Korrektur für eine Datenbeschädigung im Netzwerk und wurde auch als solche durch den Quellcode-Baum weitergeleitet.

Das ist von Bedeutung, da die meisten Patch-Workflows CVE-Feeds, Herstellerhinweise, „oss-security“ und Scanner-Updates überwachen. Bei diesem Problem wurden die Sicherheitsauswirkungen erst später offensichtlich: Der Patch war zunächst sichtbar, die CVE-Meldung traf erst beim Merge ein, und der Proof-of-Concept folgte innerhalb eines Tages. Bei Kernel-Fehlern dieser Art eröffnet das Prinzip „zuerst beheben, dann CVE melden“ ein Zeitfenster, in dem Angreifer und spezialisierte Forscher die Ausnutzbarkeit erkennen, noch bevor gewöhnliche Patch-Prozesse in Unternehmen das Problem überhaupt registrieren.

Die praktische Schlussfolgerung: Behandeln Sie öffentliche Kernel-Korrekturen, die sich auf Seiten-Cache-Korruption, partielles COW, Zero-Copy-Schreibvorgänge und die Handhabung beschreibbarer SKB-Bereiche beziehen, als potenziell sicherheitsrelevant, noch bevor ein CVE oder ein PoC erscheint.

Wer ist betroffen?

Die Sicherheitslücke hängt von drei Faktoren ab: ob „act_pedit“ geladen werden kann, ob nicht privilegierte Benutzer Zugriff haben und ob Ihre Distribution einen korrigierten Kernel enthält.

Durch einen öffentlich zugänglichen PoC als ausnutzbar bestätigt (vom Autor verifiziert, ohne Root-Rechte):

• RHEL 10.0 auf 6.12.0-228.el10 – kein Flag erforderlich; Benutzer sind standardmäßig offen
• Debian 13 „trixie“ auf 6.12.90+deb13.1 – kein Flag erforderlich
• Ubuntu 24.04.4 auf 6.17.0-22 – erfordert die Umgehung „–ubuntu aa-exec userns“

Ubuntu 26.04 (7.0.0-14) gibt „FAIL“ zurück, doch das liegt daran, dass die AppArmor-Benutzerabsicherung ihre Aufgabe erfüllt – nicht daran, dass der Kernel gepatcht wurde. Der zugrunde liegende Kernel ist nach wie vor anfällig.

Vom Hersteller festgelegt (den gepatchten Kernel installieren und neu starten):

• RHEL 10 – RHSA-2026:27288
• RHEL 9 – RHSA-2026:27789
• RHEL 8 – RHSA-2026:27353; die überarbeitete Version für AlmaLinux 8 lautet ALSA-2026:27353 (veröffentlicht am 22. Juni). RHSA-2026:27355 ist die 8.8-EUS/TUS-Variante.
• Debian 13 trixie – DSA-6355-1 (veröffentlicht am 21. Juni)

sowie die Mainline und die stabilen Backports.

Betroffen, aber noch nicht vom Hersteller behoben – die Hosts, bei denen derzeit nur vorübergehende Abhilfemaßnahmen zur Verfügung stehen und bei denen eine Patch-Abdeckung ohne Neustart nach der Veröffentlichung des Patches von größter Bedeutung ist:

• Debian 11 und 12
• Ubuntu Bionic bis Noble (24.04.4 ist ein bestätigtes PoC-Ziel)

Nicht betroffen oder noch offen:

• RHEL 7 / CentOS 7 – nicht betroffen.
• Oracle UEK 6 und UEK 7 – Status „offen“ in unserem Entwickler-Thread.

Jetzt Maßnahmen ergreifen

Der sicherste Weg besteht darin, den laufenden Kernel unverzüglich zu schützen. Dazu stehen drei praktische Maßnahmen zur Verfügung, die nach Priorität geordnet sind.

1. Patch oder Patch ohne Neustart

Installieren Sie den vom Hersteller korrigierten Kernel, sofern vorhanden, und führen Sie einen Neustart durch, sobald dies betrieblich möglich ist. Geben Sie Hosts Vorrang, auf denen teilweise vertrauenswürdiger Code ausgeführt wird: Kubernetes-Knoten, CI/CD-Runner, Shared-Hosting-Umgebungen, Entwickler- und Build-Systeme, Multi-Tenant-Plattformen sowie Container-Hosts, die nicht vertrauenswürdige Workloads akzeptieren.

Die „KernelCare“-Patches für CVE-2026-46331, die einen Neustart überflüssig machen, befinden sich derzeit in der aktiven Entwicklung und werden anhand des Upstream-Fixes getestet. Nach dem aktuellen Stand der Abdeckung wurde noch nichts in den Feeds „test“, „main“ oder „ePortal“ veröffentlicht. Sobald ein Build verfügbar ist, überprüfen Sie ihn bitte:

kcarectl --patch-info | grep -i 'CVE-2026-46331'
kcarectl --info | grep kpatch-build-time      # build dated on or after the release

2. Blockiere „act_pedit“, wenn du es nicht verwendest

act_pedit wird automatisch geladen, sobald eine „pedit tc“-Aktion konfiguriert wird. Wenn Sie keine „tc pedit“-Regeln ausführen – was bei den meisten Hosts der Fall ist –, verhindern Sie, dass es geladen wird.

Im Red Hat-Bulletin (RHSB-2026-008) wird eine Blacklist für den Systemstart empfohlen:

echo 'blacklist act_pedit' > /etc/modprobe.d/blacklist-act-pedit.conf

Eine Blacklist verhindert lediglich das automatische Laden beim Systemstart. Da act_pedit bei Bedarf automatisch geladen werden kann, sobald eine Regel darauf verweist, ist eine Installationsüberschreibung, die das Modul auf /bin/true verweist, die zuverlässigere Blockierungsmethode:

echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf

Prüfen Sie anschließend, ob sie geladen ist, und entladen Sie sie nur, wenn keine aktive Verkehrsregel davon abhängt:

lsmod | grep -w act_pedit && sudo rmmod act_pedit
lsmod | grep -w act_pedit || echo "act_pedit not loaded"

Zum Rückgängigmachen die Datei löschen:

sudo rm /etc/modprobe.d/disable-act_pedit.conf

Auswirkungsbereich: Jede Konfiguration zur Verkehrssteuerung, die „action pedit“ verwendet, kann nicht geladen werden, solange der Block aktiv ist. Einige Container-/CNI- und QoS-Konfigurationen sind davon abhängig. Wenden Sie diese Änderung daher nicht auf Hosts an, die „tc pedit“-Regeln benötigen. Überprüfen Sie dies vor einer flächendeckenden Einführung mit dem Befehl „tc actions list action pedit“.

3. Benutzernamensräume ohne Sonderrechte einschränken

Der Exploit benötigt einen nicht privilegierten Benutzer-Namespace, um die namespace-lokale Berechtigung CAP_NET_ADMIN zu erlangen. Das Schließen nicht privilegierter Benutzer-Namespaces unterbricht die öffentliche Kette unabhängig vom Status des Moduls.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf

Unter Ubuntu können Sie stattdessen die bestehenden AppArmor-Einschränkungen verschärfen (kernel.apparmor_restrict_unprivileged_userns / _unconfined), wodurch der PoC unter 26.04 standardmäßig blockiert wird.

Hinweis zur Kompatibilität: Nicht privilegierte Benutzernamensräume werden von rootless-Container-Laufzeitumgebungen, verschiedenen CI-Sandboxes, dem nicht privilegierten `unshare(1)`, sandboxierten Browsern und Flatpak benötigt. Auf gehärteten oder Hosting-Workloads akzeptabel, auf Entwickler- und Container-Hosts jedoch störend. Vor einer flächendeckenden Einführung testen.

Entscheidungsmoment

Wenn auf dem Host keine „tc pedit“-Regeln ausgeführt werden → blockieren Sie „act_pedit“; dies ist die einschränkendere Änderung. Wenn „pedit“ benötigt wird, aber keine rootless Container oder unprivilegiertes „unshare“ → beschränken Sie stattdessen die Benutzerrechte. Wenn beides benötigt wird → ist ein Patch oder ein rebootless Patch die einzige wirkliche Lösung; isolieren Sie bis dahin nicht vertrauenswürdige lokale Ausführungen.

KernelCare Rebootless Patch

Stand: 23.06.2026, 18:30 UTC: Befindet sich im aktiven Test unter dem übergeordneten Ticket KCARE-27230. Bislang liegt noch keine Veröffentlichung in den Feeds „test“, „main“ oder „ePortal“ vor. Die Arbeiten für die einzelnen Distributionen werden unter den Tickets KCARE-27167 (EL10), KCARE-27223 (EL9), KCARE-27159 (EL8) und KCARE-27204 (Debian 13) verfolgt.

Sobald ein Build im Test-Feed verfügbar ist, wenden Sie ihn wie folgt an:

kcarectl --update --prefix test

Nach der Validierung wird es beim nächsten geplanten Durchlauf bereitgestellt, oder Sie können es bei Bedarf abrufen:

kcarectl --update

Überprüfen:

kcarectl --patch-info | grep -i 'CVE-2026-46331'

Erkennung

Für „pedit-cow“ gibt es keine zuverlässige Signatur, die nach einer Kompromittierung erkennbar ist. Die Manipulation befindet sich im Seitencache, die Binärdatei auf der Festplatte bleibt unberührt, und die Spuren verschwinden, sobald die zwischengespeicherten Seiten aus dem Cache entfernt werden oder das System neu gestartet wird. Dateiintegritätsprüfungen sind in diesem Fall nur ein schwaches Indiz.

Die Verhaltenssignale, auf die es sich zu achten lohnt:

• Das Modul „act_pedit“ wird unerwartet auf Hosts geladen, auf denen keine Paketbearbeitung zur Verkehrssteuerung ausgeführt wird.
• Ungewöhnliche TC-Aktivitäten durch Benutzer oder Prozesse, die normalerweise keine Netzwerkkonfigurationen vornehmen.
• Erstellung von Benutzernamensräumen ohne Sonderrechte kurz vor der Ausführung einer setuid-Binärdatei.
• Die Ausführung von „su“, „sudo“ oder einer Shell im Anschluss an Maßnahmen zur Verkehrssteuerung ohne triftigen Grund.

Ausführung von „tc“ und das Laden von Modulen überwachen:

auditctl -w /sbin/tc -p x -k tc_exec
auditctl -w /usr/sbin/tc -p x -k tc_exec
grep act_pedit /proc/modules

Wenn Sie den Verdacht haben, dass eine Sicherheitslücke ausgenutzt wird, leeren Sie den Seitencache, um sicherzustellen, dass die Daten unverändert von der Festplatte neu geladen werden:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Betrachten Sie dies als Eindämmungsmaßnahme, nicht als Abhilfe. Wenn ein Angreifer bereits Root-Rechte erlangt hat, beseitigt eine Sperrung nicht die Persistenz, die er danach aufgebaut hat. Jeder Host, auf dem ein nicht vertrauenswürdiger lokaler Benutzer während des Sicherheitslückenzeitraums Shell-Zugriff hatte, sollte als potenziell kompromittiert behandelt werden.

Warum Fehler wie „pedit-cow“ immer wieder auftauchen

„pedit-cow“, „Dirty Pipe“, „Copy Fail“ und „Dirty Frag“ unterscheiden sich zwar in den Details, weisen jedoch ein gemeinsames Muster auf: einen leistungsorientierten Fast Path, der eine falsche Annahme darüber trifft, ob eine Seite sicher beschrieben werden kann. In jedem Fall erreichte ein Schreibvorgang eine Seite, von der der Kernel annahm, dass sie ihm gehörte, und der Seitencache wurde zum Opfer, da er konstruktionsbedingt gemeinsam genutzt wird – jeder Leser einer Datei sieht dieselbe physische Seite, sodass ein einziger fehlerhafter Schreibvorgang darauf für privilegierten Code sichtbar werden kann, der ausführbare Bytes liest.

Diese Fehler sind gerade deshalb gefährlich, weil sie eine „lokale Speicherbeschädigung“ in etwas Praktisches umwandeln. Ein Angreifer muss weder Dateiberechtigungen umgehen noch irgendetwas auf der Festplatte verändern. Er muss lediglich die im Cache gespeicherte Kopie lange genug beschädigen, damit privilegierter Code sie lesen oder ausführen kann.

Die grundlegende Lösung besteht nicht darin, „die Optimierung einzustellen“. Es geht vielmehr um stärkere Garantien für die Seitenzuordnung in allen Speicherverwaltungszweigen des Kernels – eine langwierige Aufgabe, da sie die leistungsempfindlichsten Teile des Kernels betrifft. „pedit-cow“ wird nicht der letzte Fehler dieser Art sein. Dies zeigt auch, warum eine Reaktion noch am selben Tag immer schwieriger wird: Eine Sicherheitslücke kann sich von einem harmlos aussehenden Patch über eine CVE bis hin zu einem öffentlichen Root-Exploit ausbreiten, bevor viele Organisationen einen klaren Überblick über ihre Betriebslage haben.

Checkliste für priorisierte Sanierungsmaßnahmen

1. Patch. Installieren Sie den vom Hersteller korrigierten Kernel (RHEL 8/9/10, AlmaLinux 8, Debian 13) und starten Sie das System neu. Warten Sie nicht auf den „KernelCare“-Patch, der keinen Neustart erfordert – dieser ist noch in keinem Repository verfügbar.
2. Ergreifen Sie Abhilfemaßnahmen, wo keine Patches möglich sind. Blockieren Sie „act_pedit“, wenn Sie keine „tc pedit“-Regeln verwenden, oder schränken Sie die Rechte nicht privilegierter Benutzer ein, sofern dies möglich ist.
3. Überprüfen Sie den lokalen Zugriff. Stellen Sie fest, wer auf gemeinsam genutzten Hosts, CI/CD-Runner, Build-Servern und mandantenfähigen Systemen über Shell-Zugriff verfügt. Entziehen Sie für die Dauer der Maßnahme alle nicht benötigten Zugriffsrechte.
4. Durchsuchen. Wenden Sie die Erkennungsheuristiken auf den Zeitrahmen der Bekanntmachung an, beginnend mit dem Beitrag in der Mailingliste von Ende Mai.
5. Führen Sie nach dem Patchen einen Neustart durch. Dadurch werden alle potenziell beschädigten Seiten im Cache zusammen mit dem alten Kernel gelöscht.

Referenzen

• NVD – CVE-2026-46331: https://nvd.nist.gov/vuln/detail/CVE-2026-46331
• Eintrag auf CVE.org – CVE-2026-46331
• GitHub-Sicherheitshinweis GHSA-cr2w-747q-47qc
• Red Hat RHSB-2026-008 – Rechteausweitung bei der Verkehrssteuerung und die Red Hat CVE-Seite
• Hersteller-Errata: RHSA-2026:27288 (RHEL 10), RHSA-2026:27789 (RHEL 9), RHSA-2026:27353 (RHEL 8 = AlmaLinux ALSA-2026:27353; RHSA-2026:27355 ist die 8.8-EUS/TUS-Variante), DSA-6355-1 (Debian 13)
• Debian Security Tracker – CVE-2026-46331
• Öffentlicher PoC (Massimiliano Oldani, 17.06.2026): https://github.com/sgkdev/packet_edit_meme
• netdev-Thread: v2- und v3-LKML-Mirrors; Thread-Stamm auf Spinics
• Stable fix commits (git.kernel.org/stable/c/<hash>): 899ee91156e5, 2bec122b9fb9, 3dee9d0c198f, b198ed4e5258
• KernelCare-Verfolgung: Überbegriff KCARE-27230; Patch ohne Neustart CL Gerrit 256818; distributionsspezifisch KCARE-27167 / 27223 / 27159 / 27204

Patches für jeden Kernel – ganz ohne Neustart. Wenn Sie KernelCare noch nicht nutzen, ist jetzt der richtige Zeitpunkt, um zu erfahren, wie Patches ohne Neustart kritische Linux-Systeme schützen – ganz ohne Notfall-Wartungsfenster oder Ausfallzeiten.

Erfahren Sie hier mehr über KernelCare →