Een fout in het verkeerscontrolesubsysteem van de Linux-kernel kan ervoor zorgen dat een lokale gebruiker zonder rechten root kan worden op getroffen systemen.
CVE-2026-46331, bijgenaamd “pedit KOE,” is een out-of-bounds schrijfactie in de pakketbewerkingsactie (act_pedit) die het gedeelde pagina-cachegeheugen corrumpeert. Een openbare, werkende exploit verscheen binnen een dag na de CVE-opdracht op 16 juni. Red Hat beschouwt de fout als belangrijk.
De exploit raakt nooit het bestand op schijf. Het vergiftigt de in de cache opgeslagen kopie van een setuid root-binair bestand (/bin/su) in het geheugen, injecteert een kleine payload en voert die gewijzigde afbeelding uit als root. Controles op de integriteit van bestanden komen schoon terug terwijl er al een rootshell geopend is.
De exploit heeft twee dingen nodig: act_pedit kan worden geladen en gebruikersnaamruimten zonder privileges moeten open zijn, waardoor de aanvaller een naamruimte-lokale netwerkmogelijkheid (CAP_NET_ADMIN) krijgt die nodig is om de bug te activeren.
Op de geteste RHEL- en Debian-doelen waren beide voorwaarden aanwezig.
Hoe de bug werkt
Linux’s tc traffic-control tool kan pakketheaders tijdens de vlucht herschrijven met behulp van een actie genaamd pedit. De kernelfunctie die dit doet, tcf_pedit_act(), wordt verondersteld een privékopie van de gegevens te maken voordat deze wordt bewerkt, het standaard copy-on-write-patroon.
Het controleerde het schrijfbare bereik één keer, voordat de definitieve offsets bekend waren. Sommige bewerkingssleutels lossen hun offset alleen tijdens runtime op. Wanneer dat gebeurt, komt het schrijven buiten het privé gekopieerde gebied terecht, zodat de kernel een gedeelde paginacachepagina wijzigt in plaats van een privékopie. Als die pagina tot een bestand in de cache behoort, is de afbeelding in het geheugen van het bestand beschadigd.
Het patroon is bekend. Dirty Pipe, Copy Fail, DirtyClone en Dirty Frag hebben allemaal dezelfde vorm: een snel pad van de kernel schrijft naar een pagina die het niet exclusief bezit, en de paginacache vangt de klap op.
Wat hier nieuw is, is het toegangspunt. Een gebruiker zonder rechten kan tc-acties configureren vanuit een gebruikersnaamruimte, waardoor hij of zij de CAP_NET_ADMIN krijgt die de exploit nodig heeft.
Betrokken systemen
De PoC-auteur rapporteerde exploitatie zonder privileges tot root op RHEL 10 en Debian 13 (trixie), waar gebruikersnaamruimten zonder privileges standaard open zijn. Ubuntu 24.04 vereiste uitvoering van routering via AppArmor-profielen die nog steeds gebruikersnaamruimten toestaan. Ubuntu 26.04 blokkeert dat pad standaard omdat de AppArmor-profielen niet-bevoorrechte gebruikersnaamruimten beperken, hoewel de onderliggende kernel kwetsbaar blijft.
Fixes worden opgesplitst per leverancier.
- Debian heeft trixie opgelost via zijn beveiligingskanaal. Debian 11 en 12 worden nog steeds als kwetsbaar vermeld.
- Ubuntu vermeldt ondersteunde releases van 18.04 tot en met 26.04 als kwetsbaar vanaf 25 juni.
- Red Hat vermeldt RHEL 8, 9 en 10 als getroffen; RHEL 7 wordt niet vermeld in het bulletin.
Wat te doen
Installeer de gepatchte kernel en start opnieuw op. Geef prioriteit aan systemen waarbij ‘lokale gebruiker’ niet een vertrouwde gebruiker betekent: hosts met meerdere tenants, CI/CD-runners, Kubernetes-nodes, build-workers en gedeelde onderzoeks- of laboratoriummachines.
Als je nog niet kunt patchen, doden twee oplossingen de exploitketen. Op systemen die geen tc pedit-regels nodig hebben, controleer je of de module in gebruik is (lsmod | grep act_pedit) en blokkeer je het laden:
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.confU kunt ook niet-bevoorrechte gebruikersnaamruimten uitschakelen (user.max_user_namespaces=0 op RHEL, kernel.unprivileged_userns_clone=0 op Debian/Ubuntu). Dat verwijdert de naamruimte-lokale mogelijkheden die de exploit nodig heeft, maar het vernietigt rootless containers, sommige CI-sandboxen en sandbox-browsers. Eerst testen.
Omdat het overschrijven gericht is op geheugen in de cache, is het mogelijk dat controles op de bestandsintegriteit dit niet onderkennen. Door de paginacache te verwijderen (echo 3 > /proc/sys/vm/drop_caches) wordt de vergiftigde kopie in het geheugen gewist, maar wordt niets aan de rootshell gedaan die de aanvaller al heeft geopend. Behandel de host als gecompromitteerd.
De oplossing kwam eind mei op de netdev-mailinglijst terecht, in de vorm van een routinematige patch voor gegevenscorruptie. Het exploiteerbare detail stond wekenlang op een openbare mailinglijst. Geen CVE, geen beveiligingswaarschuwing. De CVE werd toegewezen toen de oplossing op 16 juni werd samengevoegd. Het bewapende proof-of-concept volgde binnen een dag. Voor fouten in de kernelpaginacache is het wachten op een scannerregel te traag.
