v0idnetwork/cve-2026-46331pedit COW
CVE-2026-46331 (Spitzname „pedit COW“) ist eine lokale Linux-Kernel-Privilegienausweitungs-Schwachstelle im Traffic-Control-Subsystem. Ein unprivilegierter Benutzer (in einem unprivilegierten Netzwerk-Namespace) kann den act_pedit-Filter (Paket-Editor) konfigurieren, um einen partiellen Copy-on-Write (COW)-Schreibvorgang in den Seitencache auszulösen. Im Effekt schreibt der Kernel attacker-kontrollierte Daten in das In-Memory-Abbild einer Datei ohne die Seite als privat zu markieren und beschädigt dadurch die zwischengespeicherte Kopie der Datei. Entscheidend ist, dass der Exploit nur CAP_NET_ADMIN benötigt (erhältlich in einem Benutzer-Namespace) und die Datei auf der Festplatte nicht verändert. In der Praxis wurde am 17. Juni 2026 ein funktionierender Proof-of-Concept (PoC) namens packet_edit_meme veröffentlicht, der zeigt, wie man das Seitencache-Abbild einer setuid-Binärdatei (z.B. /bin/su) überschreibt, um eine Root-Shell zu öffnen. Die Schwachstelle rührt von einer fehlerhaften COW-Bereichsberechnung in tcf_pedit_act() her und wurde upstream (4. Juni 2026) durch Verschiebung der Prüfung des beschreibbaren Bereichs in die Pro-Schleife behoben.
act_pedit. Nicht gepatchte stabile Releases (einschließlich vieler Distro-Kernel) sind verwundbar.tc-pedit-Filter ein und überschreibt den ELF-Einstiegspunkt einer setuid-Binärdatei im Speicher mit Shellcode.skb_ensure_writable() in die Schlüsselschleife). Als Workaround das Modul act_pedit blockieren oder entladen oder unprivilegierte Benutzer-Namespaces deaktivieren (z.B. sysctl user.max_user_namespaces=0). Nach der Abhilfe Caches leeren (echo 3 > /proc/sys/vm/drop_caches), um vergiftete Seiten zu vertreiben.Dieser Bericht bietet eine detaillierte technische Analyse von CVE-2026-46331: Ursache, Ausnutzung, Erkennung und Abhilfestrategien, mit Verweisen auf Herstellerhinweise, CVEs und den öffentlichen Exploit.
Definition: CVE-2026-46331 ist ein Out-of-Bounds-Schreibfehler im Traffic Control (net/sched)-Subsystem des Linux-Kernels, speziell in der act_pedit-Aktion (Paket-Editor). Die Funktion tcf_pedit_act() berechnet einen „Copy-on-Write“-Bereich für Paketbearbeitungsoperationen bevor sie über typisierte Schlüssel iteriert, unter Verwendung eines statischen Hinweises tcfp_off_max_hint. Allerdings bestimmen einige Schlüssel (z.B. TCP/UDP-Headerbearbeitungen) ihren endgültigen Byte-Offset erst zur Laufzeit. Der Code überprüft die Beschreibbarkeit für diese dynamischen Offsets nie erneut. Infolgedessen können Schreibvorgänge außerhalb des zuvor COW-geschützten Bereichs auftreten: Ein Teil des Paketschreibvorgangs wird nie privat gemacht, was zu einem partiellen COW führt. Dieser fehlerhafte Schreibvorgang breitet sich in den gemeinsamen Seitencachespeicher einer Datei aus (falls die Paketpuffer zufällig auf Dateiseiten verweisen) und beschädigt das zwischengespeicherte Dateiabbild.
Hintergrund: Die Linux-Paket-Editor (pedit)-Aktion ermöglicht es Administratoren, beliebige Bytes innerhalb von Paketheadern (Link-, Netzwerk- oder Transportschicht) umzuschreiben, während Pakete einen konfigurierten tc-Filter durchlaufen. Es funktioniert durch Angabe eines Offsets (möglicherweise an einem Header verankert) und eines 32-Bit-Werts/Maske. Intern arbeitet pedit auf Socket-Puffern (sk_buff) und muss den Zielpaketspeicher beschreibbar machen, bevor er ihn modifiziert (über skb_ensure_writable() in COW-Manier). Idealerweise sollte der Kernel alle gemeinsam genutzten Seiten klonen (private Kopie erstellen), bevor er darauf schreibt, um zu vermeiden, dass an anderer Stelle verwendeter Speicher verändert wird.
Grundursache: In tcf_pedit_act() berechnet der Code den beschreibbaren Bereich fälschlicherweise nur einmal vorab, unter Verwendung von tcfp_off_max_hint (dem maximalen statischen Offset). Dieser Hinweis enthält keinen Laufzeit-Header-Offset, den typisierte Schlüssel bei der Verarbeitung des Pakets hinzufügen. Schlüssel wie TCP oder UDP können einen Offset basierend auf der Position des IP-Headers zur Laufzeit berechnen (z.B. wenn ein früherer Schlüssel den Netzwerk-Header verschiebt). Somit kann während der Schleife der tatsächliche Offset für einen Schlüssel den Bereich überschreiten, der als beschreibbar vorab zugewiesen wurde. Der Code schreibt dann über skb_store_bits() in den Paketspeicher, aber da die Seite außerhalb des zuvor COW-geschützten Bereichs nicht privat gemacht wurde, beschädigt der Schreibvorgang eine Seite, die noch mit dem Seitencache geteilt wird. Kurz gesagt: „Den beschreibbaren Paketbereich zu früh berechnen“ verursacht einen Out-of-Bounds-Schreibvorgang über mehrere Seiten. Negative Offsets (z.B. Bearbeitung von Ethernet-Headern beim Eingang) werden ebenfalls falsch behandelt, und sogar offset_valid() enthält keine Prüfung auf INT_MIN, was die Schwachstelle verstärkt.
Warum es passiert: Dieser Fehler ist im Wesentlichen ein Logikfehler in der Berechnung des Copy-on-Write-Bereichs. Der Kernel nahm an, dass der statische maximale Offset (zum Ladezeitpunkt bekannt) für alle Bearbeitungen ausreiche. Er versäumte es, den COW-Bereich zu aktualisieren, wenn Schlüssel mit dynamischen Offsets tatsächlich angewendet wurden. Nach einer Reihe von Bearbeitungsschritten konnte der endgültige Schreibvorgang außerhalb des vorab geprüften Bereichs liegen. Da Paketpuffer auf speichergemappte Dateiseiten verweisen können (z.B. über Zero-Copy-Mechanismen), kann dieser „partielle COW“-Schreibvorgang den Seitencache einer Datei auf der Festplatte erreichen, ohne die Festplatte zu verändern.
Components and Data Flow: Der verwundbare Code befindet sich im Linux-net/sched-Subsystem (act_pedit.c). Wenn ein Paket eine konfigurierte pedit-Regel erfüllt, wird tcf_pedit_act() aufgerufen. Intern ruft es genau einmal skb_ensure_writable(skb, X) auf, wobei X = tcfp_off_max_hint ist. Dadurch werden die ersten X Bytes des Pakets privat gemacht (COW). Dann wird in einer Schleife über jeden Schlüssel (Bearbeitungsoperation) der tatsächliche Schreiboffset des Schlüssels berechnet, indem der Laufzeit-Header-Offset zum angegebenen Offset des Schlüssels addiert wird, und ein 32-Bit-Wert in das Paket geschrieben. In Pseudocode:```c
u32 off_max = action->tcfp_off_max_hint;
skb_ensure_writable(skb, off_max);
for (i = 0; i < num_keys; i++) {
u32 hdr_off = compute_header_offset(skb, key[i].hdr_type);
u32 write_off = hdr_off + key[i].offset;
skb_store_bits(skb, write_off, &key[i].value, 4);
}
Da `hdr_off` nur bei der Verarbeitung jedes Schlüssels berechnet wird, berücksichtigte der anfängliche `skb_ensure_writable()`-Aufruf dies nicht. Wenn `hdr_off + key[i].offset` `off_max` überschreitet, greift der Code auf `skb_store_bits()` auf Fragmenten zurück, anstatt auf den linearen Hauptbereich, was bedeutet, dass er in eine Seite schreibt, die nicht privat gemacht wurde. Das ist der Fehlerpunkt.
**Angriffsfläche:** Die einzige benötigte Schnittstelle ist der **tc-Filter** mit einer `pedit`-Aktion, die normalerweise die Fähigkeit **CAP_NET_ADMIN** erfordert. Gewöhnliche Benutzer können CAP_NET_ADMIN jedoch innerhalb eines privaten Netzwerk-Namensraums (User-Namespace-Cloning) ohne echte Privilegien erlangen. Somit kann ein unprivilegierter Benutzer einen User+Net-Namespace betreten und eine `tc pedit`-Regel auf Loopback erstellen. Der Schreibvorgang erfolgt, wenn ein Paket verarbeitet wird (der Angreifer generiert typischerweise Datenverkehr auf Loopback, um ihn auszulösen). Die Vertrauensgrenze (Benutzer vs. Kernel) wird überschritten, weil der Kernel seiner eigenen COW-Einrichtung vertraute, die vom Benutzer bereitgestellten Offsets diese Annahme jedoch brachen.
**Interner Mechanismus:** Auf Kernelseite manifestiert sich die Schwachstelle als **Schreibzugriff außerhalb der Grenzen** (CWE-787). Sie beschädigt den Kernel-Speicher, der in den Benutzerbereich abgebildet ist (Dateiseiten-Cache). Insbesondere kann sie den Inhalt jeder Dateiseite überschreiben, die zufällig in den Socket-Puffer abgebildet ist. Im Proof-of-Concept wird `/bin/su` durch Senden in den Socket-Puffer gemmaped, sodass der Exploit seine Eintrittspunkt-Bytes im Speicher umdreht. Dies ändert die Datei auf der Festplatte nicht, aber jede spätere Ausführung dieser Binärdatei liest das vergiftete Image aus dem Cache. Die Blog-Analyse stellt fest:
> „Da der skb über sendfile eingezogene Zero-Copy-Seiten referenzieren kann, kann dieser Schreibzugriff außerhalb der Grenzen im gemeinsam genutzten Page-Cache-Speicher landen, der eine reale Datei unterstützt. Der Kernel glaubt, er hätte den Paketspeicher sicher zum Ändern gemacht; in Wirklichkeit erreicht der spätere Schreibzugriff eine Region außerhalb des Bereichs, den er tatsächlich privatisiert hat.“
**Vertrauensgrenzen:** Der Kernel nahm fälschlicherweise an, dass `skb_ensure_writable()` (COW-Schnellpfad) die Sicherheit für alle nachfolgenden Schreibvorgänge garantieren würde. Er prüfte nicht für jeden Schlüssel erneut. Der Benutzer kontrolliert nur die Paketfilter-Konfiguration und den Paketinhalt; der Kernel gewährte dies (durch Netzwerk-Namensräume). Sobald dieses Vertrauen verletzt war, entkam der Schreibzugriff in dateigestützten Speicher, der eigentlich hätte geschützt werden sollen.
## Ursachenanalyse
Die Grundursache ist eine **falsche COW-Bereichsberechnung in der pedit-Aktion**. Im Code wurde ein einzelner `skb_ensure_writable()`-Aufruf mit einer Länge basierend auf `tcfp_off_max_hint` ausgeführt, dann konnten die tatsächlichen Offsets in der Schleife diesen überschreiten. Ein kleiner Patch (Mai 2026) behebt dies, indem `skb_ensure_writable()` *innerhalb* der Schleife platziert wird, nachdem der wahre Offset bekannt ist, und durch Hinzufügen von Prüfungen und speziellen Handhabungen für negative Offsets. Mit anderen Worten:
- **Fehlerhafter Code:** ```c
skb_ensure_writable(skb, action->tcfp_off_max_hint);
for each key:
// compute offset (hdr_off + key_offset)
skb_store_bits(skb, write_off, ...);
Additionally, the fix ensures that for negative offsets (Ethernet header edits) it uses skb_cow() on headroom, and guards against INT_MIN cases. The commit message (stack.watch summary) states: “Fix by moving skb_ensure_writable() inside the per-key loop where the actual write offset is known, and add overflow checking on the offset arithmetic.”.
Thus, why it exists: during code review or design, the per-key re-calculation was overlooked. The static hint optimization bypassed the need to re-evaluate per key. It appears to be an honest bug rather than a malicious oversight, but its effect is severe because it violates the COW assumption. As TuxCare notes, this bug was merged under the guise of a routine “data corruption” fix, without immediate security context.
The vulnerability was introduced by kernel commit 8b796475fd78 (May 2022) and remained unnoticed until early 2026. According to sources, the fix (commit 899ee91156e5 on May 31, 2026) was submitted to the netdev mailing list as an ordinary data-corruption patch. The kernel maintainers merged the fix (net-7.1-rc7) on June 4, 2026. Only on June 16, 2026 was CVE-2026-46331 formally assigned (about two weeks after the patch appeared). A fully weaponized public exploit appeared on June 17, 2026 (the packet_edit_meme PoC).
In practice, the sequence was:
Multiple parties noticed the bug by the open patch. For example, Massimiliano Oldani (cybersecurity researcher) published a detailed write-up and exploit shortly after, noting that “a public, working proof-of-concept exploit named packet_edit_meme appeared on GitHub within 24 hours of CVE assignment”. CloudLinux, TuxCare, and SentinelOne published analyses once the PoC was public and CVEs assigned. The Debian security tracker and PT DBugs also summarized the issue and available advisories (see References).
A realistic attack requires minimal preconditions:
Attacker capabilities: A local unprivileged user on the target machine. The user must be able to create a new user namespace with network namespace (via unshare(CLONE_NEWUSER|CLONE_NEWNET)), which grants CAP_NET_ADMIN inside that namespace without real root privileges. Unprivileged user namespaces are enabled by default on many kernels (e.g. RHEL, Debian) and can be re-enabled on Ubuntu with an aa-exec workaround.
Target conditions: The target must be running a vulnerable Linux kernel (approx. 5.18–7.1-rc6) with the act_pedit module available. If act_pedit is built-in or already loaded, it is immediately exploitable. If it is a module, it auto-loads when a tc pedit rule is configured. The target should not have applied the upstream patch. Notably, it is not necessary for the attacker to have write access to any file; the exploit works by writing through packet filters.
Attack chain:
unshare --map-root-user --net --pid bash to create a new user+net namespace. This grants CAP_NET_ADMIN in that namespace (user mapped to root inside).ifconfig lo up) and optionally spawns a listener (e.g. nc -l 127.0.0.1 9999). This provides a packet flow to use for TC actions.Impact: If successful, the attacker gains full root privileges locally. The exploit can be done in one command and is deterministic. Additionally, corruption of arbitrary file-backed pages could cause denial-of-service (system crash) if used differently. The published PoC specifically overwrote /bin/su’s entrypoint with shellcode, but any file the attacker can map could be targeted. The chain requires no special timing or race and has been demonstrated on many distros (RHEL, Ubuntu, Debian, etc.).
A public exploit, packet_edit_meme, is available on GitHub (sgkdev/packet_edit_meme) and targets /bin/su. We describe its essential logic without destructive payloads:```c
/* Pseudocode outline of the exploit (simplified) /
int main() {
/ 1. Identify a setuid binary (su) and its ELF entry offset */
int fd = open("/bin/su", O_RDONLY);
long entry = elf_entry_offset(fd);
if (entry < 0) abort();
printf("Target %s (UID=%d), entry offset 0x%lx\n", "/bin/su", getuid(), entry);
/* 2. Unshare user+net namespace to get CAP_NET_ADMIN locally */
if (unshare(CLONE_NEWUSER | CLONE_NEWNET) < 0) abort();
/* Map UID/GID to root (handled via /proc/self/uid_map, /gid_map) */
// (omit details: write "0 <uid> 1" to /proc/self/uid_map and gid_map, and deny setgroups)
/* 3. Setup environment: bring up loopback and listener */
if (system("ip link set lo up") < 0) abort();
if (system("nc -l 127.0.0.1 9999 &") < 0) abort();
/* 4. Configure a tc pedit action via netlink (simplified) */
// Assume 'pedit_write' sends a packet-edit command to the kernel.
// The key offsets below are chosen such that they exceed the initial COW range.
char shellcode[/*size=48*/] = {
// (assembly for setgid(0); setuid(0); execve("/bin/sh").., padded to 36 or 48 bytes)
};
size_t total = sizeof(shellcode), sent = 0;
while (sent < total) {
int chunk = min(PEDIT_MAX_WRITE, total - sent);
/* Issue TC pedit action to write next chunk */
if (pedit_write(fd, entry + sent, &shellcode[sent], chunk) != 0) {
fprintf(stderr, "pedit_write failed\n");
exit(1);
}
sent += chunk;
}
/* 5. Trigger execution of su (in original namespace) */
execl("/bin/su", "su", NULL); // This will run the poisoned binary as root
return 0;
}
Dieser Pseudocode veranschaulicht den Ablauf: Öffne `/bin/su`, entkopple Namespaces, um CAP_NET_ADMIN zu erlangen, konfiguriere Loopback- und TC-pedit-Regeln, rufe dann eine Funktion `pedit_write(fd, offset, data, len)` auf (im eigentlichen PoC werden darunter Netlink-Aufrufe verwendet), um den Seiten-Cache des Ziels zu überschreiben. Schließlich wird die Binärdatei ausgeführt, die eine Root-Shell erzeugt.
Der tatsächliche PoC ist aufwändiger (behandelt UID/GID-Mappings, Netzwerküberwachung und Shellcode-Bytes auf Syscall-Ebene), aber das Kernkonzept ist wie oben beschrieben. Wir betonen, **diesen Exploit nicht auszuführen**, es sei denn in einer sicheren Testumgebung, und keine echten Systeme anzugreifen. Das oben Genannte dient nur der Demonstration.
**Hinweis:** Falls kein öffentlicher, sicher nutzbarer PoC existierte, würden wir dies ausdrücklich angeben. In diesem Fall ist der PoC öffentlich und wir beschreiben ihn konzeptionell. Wir haben die rohen Shellcode-Bytes und die tatsächlichen Netlink-Details aus Gründen der Kürze und Sicherheit weggelassen.
## Exploitationsablauf
1. **Einstiegspunkt:** Der Angreifer muss zunächst CAP_NET_ADMIN erlangen. Typischerweise bedeutet dies, ein Benutzer- und Netzwerk-Namespace (`unshare`) von einem unprivilegierten Prozess zu erstellen, der namespace-lokales CAP_NET_ADMIN gewährt.
2. **Erstzugriff:** Innerhalb dieses Namespace kann der Angreifer normale Tools (`ip`, `tc`) verwenden, um die Verkehrssteuerung zu konfigurieren. Der Kernel-Pfad `act_pedit` ist nun für Pakete erreichbar.
3. **Auslöser:** Der Angreifer richtet einen `tc filter ... action pedit` auf der Loopback-Schnittstelle ein. Dieser Filter matcht Pakete (z.B. 0-Match) und spezifiziert einen oder mehrere **typisierte Schlüssel** mit Header-Typen (IP, TCP) und Offsets. Die Offsets werden so gewählt, dass *nachdem der Kernel den Header-Basiswert innerhalb der Schleife berechnet hat*, der endgültige Schreib-Offset den anfänglichen COW-Bereich überschreitet.
4. **Ausnutzung:** Wenn ein Paket, das dem Filter entspricht, verarbeitet wird, ruft der Kernel `tcf_pedit_act()` auf. Es führt ein *unzureichendes* `skb_ensure_writable()` durch und iteriert dann über die Schlüssel. Bei mindestens einem Schlüssel landet der Schreibzugriff auf einer Seite, die *nicht* in eine private Kopie geklont wurde. Dies verursacht einen **Schreibzugriff außerhalb der Grenzen** (out-of-bounds write) in den gemeinsamen Seiten-Cache. Wenn der Socket-Puffer so vorbereitet wurde, dass er auf Seiten einer Datei verweist (über sendfile/splice), dann korrumpiert dieser Schreibzugriff diese Dateiseiten.
5. **Post-Exploitation:** Der Shellcode des Angreifers wurde in den Page-Cache der Ziel-Binärdatei (z.B. `/bin/su`) geschrieben. Der Angreifer (im ursprünglichen Namespace) führt dann `/bin/su` aus. Der Kernel liest das In-Memory-Image (mit der injizierten Nutzlast) und führt den Shellcode aus, wodurch der Angreifer eine Root-Shell erhält. Zu diesem Zeitpunkt ist das gesamte System kompromittiert.
6. **Auswirkungen:** Der Angreifer erlangt Root-Rechte. Vertrauliche Daten könnten überschrieben, aber nicht direkt preisgegeben werden. Die Integrität ist vollständig gebrochen (der Angreifer kann das Speicherabbild jeder Datei ändern). Die Verfügbarkeit kann ebenfalls beeinträchtigt werden (fehlerhaftes Beschreiben kritischer Seiten könnte Prozesse oder das System zum Absturz bringen). CVSS-Metrik: Insgesamt mittel (CVSS 3.1=6.0), aber die tatsächlichen Auswirkungen sind schwerwiegend: lokaler Root.
Dieser Ablauf ist diagrammatisch zusammengefasst:```mermaid
flowchart LR
A[Attacker (unprivileged user)] --> B[Unshare into user+net namespace<br>(gains CAP_NET_ADMIN)]
B --> C[Configure TC pedit filter on lo]
C --> D{Packet processing by kernel}
D --> E[act_pedit computes wrong COW range]
E --> F[skb_store_bits writes beyond COW'd region]
F --> G[Page cache of target file is corrupted]
G --> H[Attacker executes poisoned setuid binary]
H --> I[Root shell obtained]
act_pedit erscheint unerwartet in lsmod auf Systemen, die normalerweise kein tc pedit verwenden. (Z. B. ist lsmod | grep act_pedit auf Webservern nicht leer.)tc-Nutzung: Ungewöhnliche tc-Befehle oder Netlink-Nachrichten von unprivilegierten Prozessen. Audit-Logs können zeigen, dass CAP_NET_ADMIN an einen Nicht-Root-Prozess vergeben wurde.netstat -tulnp, das nc oder einen benutzerdefinierten Listener auf 127.0.0.1 anzeigt, ein Hinweis sein.tcf_pedit_act, skb_ensure_writable oder Soft-Lockups bei starkem Datenverkehr auf Loopback oder Fehler bei der tc-Verarbeitung betreffen. (Diese wären ungewöhnlich und würden auf eine Beschädigung hindeuten.)Ein Beispiel für eine IOA sind beschädigte Dateien im Page-Cache: Eine Triage-Checkliste könnte enthalten, den Inhalt von Dateien im Speicher mit der Festplatte zu vergleichen, insbesondere bei setuid-Binärdateien nach starker tc-Aktivität. Ein weiteres Beispiel ist die Erstellung neuer Namespaces: Aufrufe von unshare(CLONE_NEWUSER|CLONE_NEWNET) könnten überwacht werden. Kurz gesagt, Verteidiger sollten auf jegliche der folgenden Aktivitäten achten: act_pedit-Nutzung, userns-Nutzung und plötzliche Änderungen von ausführbaren Dateien im RAM.
Zur Erkennung von Exploit-Versuchen:
tc-Konfigurationen oder Netlink-Nachrichten, die einen act_pedit-Filter hinzufügen. Beispielsweise könnten Sigma-Regeln nach Ereignissen suchen, die TCA_ACT_KIND: pedit oder Ähnliches enthalten. Überwachen Sie Audit-Logs auf capset CAP_NET_ADMIN von Nicht-Root-Prozessen oder Schreibvorgänge in /proc/*/uid_map./bin/su (oder andere sensible Binärdateien) lesen und diese plötzlich in Verbindung mit Namespace-/unshare-Syscalls ausführen. Alarmieren Sie bei jedem Prozess, der sowohl eine setuid-Binärdatei öffnet als auch einen userns erstellt.skb_ensure_writable() nicht ausgetrickst werden kann (obwohl es keine bekannte eingebaute Prüfung gibt).Zusammenfassend sollten Verteidiger die Nutzung von User-Namespaces, tc-Befehle und Modulladungen protokollieren und prüfen. Ein wichtiger Ansatz: jede Verwendung von tc pedit durch nicht vertrauenswürdige Benutzer ablehnen oder protokollieren. Auf kompromittierten Hosts prüfen, ob /etc/modprobe.d/disable-act_pedit.conf angewendet wurde (es sollte proaktiv sein).
Patches einspielen: Die primäre Lösung ist ein Kernel-Update. Alle großen Distributionen haben im Juni 2026 Updates veröffentlicht. Ein Upgrade auf einen gepatchten Kernel (Linux 7.1.0 oder höher, oder Backports der Distribution) ist die endgültige Lösung.
Konfigurationsänderungen: Wenn ein Patchen nicht sofort möglich ist, implementieren Sie Abschwächungsmaßnahmen:
act_pedit deaktivieren: Wenn Ihre Arbeitslasten kein tc pedit benötigen, blockieren Sie das Modul. Beispiel: ```
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf
lsmod | grep -w act_pedit && sudo rmmod act_pedit
Dies stellt sicher, dass die Aktion nicht geladen werden kann. (Dies wird von CloudLinux und TuxCare empfohlen.) Nicht auf Hosts anwenden, die tc pedit legitim verwenden.
Unter Ubuntu 22.04+: ``` sudo sysctl -w kernel.unprivileged_userns_clone=0 echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf
Dies verhindert, dass unprivilegierte Benutzer den erforderlichen Benutzernamespace erstellen können, um CAP_NET_ADMIN zu erlangen. Hinweis: Das Deaktivieren von Namespaces kann rootless Container und einige Sandbox-Anwendungen beeinträchtigen.
- **Page Cache leeren (Eindämmung):** Wenn Sie vermuten, dass der Exploit ausgeführt wurde, könnten die im Arbeitsspeicher befindlichen Kopien von Binärdateien infiziert sein. Leeren Sie sofort die Caches, um sie zu entfernen: ```
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"
Dies erzwingt ein erneutes Laden der Seiten von der Festplatte. Achtung: Falls ein Angreifer bereits Root-Rechte hatte, entfernt das Leeren der Caches keine von ihm installierte Persistenz. Behandeln Sie solche Hosts als kompromittiert.
Prinzip der geringsten Rechte: Überprüfen und beschränken Sie, wer tc verwenden darf. Der Exploit benötigt nur CAP_NET_ADMIN; stellen Sie sicher, dass nur vertrauenswürdige Admins diese Fähigkeit haben. Verwenden Sie RBAC oder Containerisierung, um die Vergabe von Capabilities einzuschränken.
Netzwerkkontrollen: Obwohl nicht direkt netzwerkfähig, stellen Sie sicher, dass Loopback-Nutzung überwacht wird. Firewall-Regeln für 127.0.0.1 sind unpraktikabel, aber stellen Sie sicher, dass nur localhost-Verkehr für TC-Manipulationen verwendet wird.
Herstellerhinweise: Beachten Sie die offiziellen Sicherheitshinweise Ihres Betriebssystems. Red Hat hat RHSA-2026:27354 (und weitere) für RHEL 8/9/10, Debian hat DSA-6355-1, Ubuntus CVE-Seite listet aktualisierte Kernel auf, usw. (Siehe Referenzen.)
Die langfristige Behebung besteht darin, sicherzustellen, dass alle betroffenen Systeme auf aktualisierten Kerneln laufen. Kernel-Pakete, die den Fix enthalten, sollten installiert und die Systeme neu gestartet werden. Für Container oder Systeme, die nicht neu gestartet werden können, sollten Livepatch-Lösungen (z.B. KernelCare) in Betracht gezogen werden, die Patches vorbereitet haben.
Zusätzlich sollte das Systemdesign davon ausgehen, dass sich benutzerzugängliche Kernel-Schnittstellen im Laufe der Zeit ändern können. Die Einschränkung von CAP_NET_ADMIN und die Filterung der tc-Nutzung sind über diesen Fehler hinaus gute Praktiken.
Falls ein Kompromittierung stattgefunden hat, bauen Sie das System neu auf. Die Schwachstelle vergiftet nur den Page-Cache, aber ein Angreifer mit Root-Rechten könnte andere bösartige Aktionen durchgeführt haben; eine forensische Validierung ist erforderlich. Verlassen Sie sich nicht auf Dateiintegritäts-Scans nach dem Exploit, da, wie erwähnt, der PoC die Dateien auf der Festplatte intakt lässt. Neustart und Patchen sind der sichere Behebungsweg.
Angesichts dieser Faktoren ergibt sich ein typischer CVSS v3.1-Vektor von AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H, was zu einem Basis-Score von 6.0 (Mittel) führt. Beachten Sie jedoch, dass CVSS nicht erfasst, dass diese Schwachstelle eine Rechteausweitung auf Root gewährt, was in der Praxis kritisch ist. (Einige Quellen berechneten CVSSv4 für ähnliche Fehler; z.B. listet PT DBugs 8.5 auf CVSSv4.)
Der Schweregrad wird von den Herstellern oft als Wichtig/Kritisch eingestuft. Red Hats Advisory für diese CVE stuft sie als Wichtig ein, und AWS markiert sie als Mittel (CVSS 6.0). In jedem Fall ist das praktische Risiko aufgrund der erlangten Root-Rechte auf Mehrbenutzer- oder gemeinsam genutzten Systemen am höchsten.
Diese Schwachstelle gehört zu einer Familie von Page-Cache-Poisoning-Fehlern. Andere bemerkenswerte CVEs sind:
splice() auf einer Pipe in den Page-Cache jenseits der COW-Grenzen schreiben konnte. Er erlaubte ebenfalls das Überschreiben von Dateien im Speicher (ohne Änderung auf der Festplatte)./proc/self/mem Copy-on-Write, der lokales Schreiben in schreibgeschützte Mappings ermöglichte.Jeder dieser Fehler betrifft einen Kernel-Schnellpfad, der in Speicher schreibt, von dem er glaubte, er gehöre ihm exklusiv, was aber nicht der Fall war. CVE-2026-46331 ist insofern einzigartig, als er in der net/sched pedit action auftritt und Benutzer-Namespaces nutzt, um Privilegienbeschränkungen zu umgehen. Im Gegensatz zu DirtyPipe oder Dirty COW wird kein zusätzlicher privilegierter Prozess (wie ein fehlkonfiguriertes System) benötigt – ein einzelner unprivilegierter Benutzer kann ihn auslösen.
Alle Referenzen stammen von seriösen Quellen (Herstellerhinweise, veröffentlichte Analysen, CVE/NVD-Einträge).
act_pedit ermöglichte die zu frühe Berechnung der Schreibbarkeit die Page-Cache-Korrumpierung.tc command or netlink, the attacker creates a qdisc and filter on lo that matches all packets (e.g. match u32 0 0) and attaches a pedit action with specially crafted keys. Each key has a dynamic header type (e.g. IP header for an L4 offset) and an offset chosen so that the actual write position (header start + offset) lies just beyond the range skb_ensure_writable() covered.echo '' > /dev/udp/127.0.0.1/53) to trigger the filter. The kernel calls tcf_pedit_act(), allocates a COW range, then iterates the keys. At least one key’s write falls outside the pre-COW’d region, causing the write to go into the shared pagecache./bin/su into the socket via sendfile or similar, so the packet buffer references that file’s pages. The out-of-bounds write then corrupts the in-memory copy of /bin/su (specifically the ELF entry point)./bin/su). Because the kernel has inadvertently injected shellcode that does setgid(0); setuid(0); execve("/bin/sh"), running su drops a root shell. The file on disk was never altered, so no on-disk file integrity tools will show a change.auditd), die zeigen, dass Programme über userns CAP_NET_ADMIN erlangen oder in /proc/[pid]/uid_map schreiben.