Dirty Frag (CVE-2026-43284 en CVE-2026-43500): wat de Linux kernel root-exploit van 7 mei betekent en hoe je je vandaag wapent

INHOUD

    Op donderdag 7 mei 2026 publiceerde onderzoeker Hyunwoo Kim via de oss-security mailing list de details van Dirty Frag, een keten van twee Linux kernel local privilege escalation kwetsbaarheden die samen in één commando elke unprivileged gebruiker tot root maken. De volgende ochtend (8 mei) werden de twee CVE’s officieel toegekend: CVE-2026-43284 voor de IPsec ESP-helft (esp4 en esp6) en CVE-2026-43500 voor de rxrpc-helft. Een publieke proof-of-concept stond al online voordat distributies hadden kunnen coördineren, en patches rolden binnen 24 uur uit naar de eerste production-repositories.

    Dirty Frag is de tweede kernel-LPE in één week (Copy Fail volgde op 29 april) en is daarmee voor iedereen die Linux servers beheert reden om vandaag de patch-cyclus, monitoring en module-hardening tegen het licht te houden. In dit artikel lees je hoe Dirty Frag technisch werkt, welke systemen kwetsbaar zijn, welke patches al beschikbaar zijn en welke mitigatie je kunt toepassen als rebooten nu niet uitkomt.

    Wat is Dirty Frag?

    Dirty Frag is een combinatie van twee kernel-bugs in dezelfde code-zone: het IPsec ESP-subsysteem en het rxrpc-protocol. De aanval is een lokale privilege-escalatie zonder race-conditie. Elke gebruiker met een shell op het systeem kan in één commando root worden. De kernel.org CNA scoort CVE-2026-43284 op CVSS 3.1 8.8 (High); voor CVE-2026-43500 hanteert Canonical een score van 7.8 (High).

    • CVE-2026-43284: de ESP-helft, in modules esp4 en esp6. Deze modules zijn op alle gangbare distributies onderdeel van de standaard kernel.
    • CVE-2026-43500: de rxrpc-helft, in module rxrpc. Aanwezigheid van deze module verschilt per distributie. Op AlmaLinux 8 wordt rxrpc niet eens gebouwd; op AlmaLinux 9 en 10 zit het in kernel-modules-partner uit de Devel-repository die buiten de standaardrelease valt; op Debian, Ubuntu en andere upstream-distributies kan rxrpc onderdeel zijn van de standaard kernelmodules.

    De volledige aanval gebruikt de ESP-bug als primaire weg naar root; de rxrpc-bug is een tweede pad door hetzelfde foutgedrag, op een ander module-oppervlak.

    Technische oorzaak: in-place decryptie over niet-eigen pages

    De fout zit in de in-place decryption fast paths van esp4, esp6 en rxrpc. Wanneer een socket buffer (skb) paged fragments draagt die niet privately owned zijn door de kernel (bijvoorbeeld pipe-pages die via splice(2), sendfile(2) of MSG_SPLICE_PAGES aan de socket zijn aangehecht), decrypteert het receive-path direct over die externally-backed pages. Het resultaat: een unprivileged proces dat nog een referentie op die pages houdt, ziet of corrupt de plaintext.

    Voor de aanvaller levert dit een schrijfprimitief in de page cache op. Door een geschikte sleutelstroom te kiezen kan de inhoud van read-only bestanden zoals /etc/passwd en /usr/bin/su in de page cache worden aangepast. Bij de volgende uitvoering pakt de kernel die gemanipuleerde pages op uit de cache, niet vers van disk, en is de aanvaller root. De upstream-fix voor ESP staat op mainline als commit f4c50a4034e6; de rxrpc-fix ging een paar uur later door het netdev-tree, gehoed door Steffen Klassert.

    Welke Linux-systemen zijn kwetsbaar?

    Zo goed als elke Linux-distributie die op 7 mei 2026 niet gepatcht was. Het AlmaLinux Security Team formuleert het kort en duidelijk: “Dirty Frag immediately yields root on all major distributions. Every supported AlmaLinux release is affected.” Hetzelfde geldt voor Ubuntu, Debian, RHEL, CentOS Stream, Rocky Linux, openSUSE en CloudLinux.

    Specifiek voor CVE-2026-43500 (rxrpc) hangt het ervan af of het rxrpc-pakket op de host aanwezig is. Op een typische server zonder AFS/Kerberos rxrpc-workload is dit doorgaans niet het geval, maar je controleert dit met:

    # Toont je huidige kernel
    uname -r
    
    # Geeft aan of esp4, esp6 of rxrpc nu geladen zijn
    lsmod | grep -E '^(esp4|esp6|rxrpc)'
    
    # AlmaLinux specifiek: is het pakket dat rxrpc levert geinstalleerd?
    rpm -q kernel-modules-partner

    Belangrijk: ook wanneer lsmod nu niets toont, kan een unprivileged user de modules via autoload triggeren. De afwezigheid van een geladen module is geen garantie dat je veilig bent.

    Patches per distributie

    AlmaLinux heeft op 7 mei gepatchte kernels naar de testing-repository gepubliceerd en op 8 mei (15:22 UTC) naar de production-repositories doorgezet. De versies zijn:

    • AlmaLinux 8: kernel-4.18.0-553.123.2.el8_10 en hoger
    • AlmaLinux 9: kernel-5.14.0-611.54.3.el9_7 en hoger
    • AlmaLinux 10: kernel-6.12.0-124.55.2.el10_1 en hoger (de combinatiebuild met ook de rxrpc-fix is kernel-6.12.0-124.55.3.el10_1)
    • AlmaLinux Kitten 10: de volgende reguliere kernel-build in de Kitten-repository

    Updaten op AlmaLinux verloopt sinds 8 mei via de standaard upgrade-flow:

    sudo dnf clean metadata && sudo dnf upgrade
    sudo reboot

    Andere distributies leveren patches via hun gebruikelijke kanalen. Volg de officiële advisories:

    Mitigatie als je niet direct kunt patchen

    Voor servers die niet direct kunnen rebooten (een wijzigingsvenster, eerst regressietests, of een productiekritiek workload zonder live-patching) blacklist je de drie kwetsbare modules. De drie regels hieronder schrijven een modprobe-config die laden van esp4, esp6 en rxrpc voorkomt, en lossen de modules direct als ze al geladen zijn. Het werkt gelijk op AlmaLinux, Rocky, RHEL, CentOS Stream, Ubuntu en Debian.

    echo 'install esp4 /bin/false' | sudo tee /etc/modprobe.d/dirtyfrag.conf > /dev/null
    echo 'install esp6 /bin/false' | sudo tee -a /etc/modprobe.d/dirtyfrag.conf > /dev/null
    echo 'install rxrpc /bin/false' | sudo tee -a /etc/modprobe.d/dirtyfrag.conf > /dev/null
    sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

    Vermoed je dat je systeem mogelijk al doelwit was voordat de mitigatie actief werd, leeg dan de page cache zodat eventueel gemanipuleerde pages opnieuw vers van disk gelezen worden:

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

    Belangrijk: pas dit niet toe op servers die actief IPsec ESP-transport of AFS/rxrpc gebruiken. Die workloads breken zonder de modules. Voor zulke systemen is de juiste oplossing een gepatchte kernel installeren en herstarten, eventueel met KernelCare live patches als kort overbruggingsmiddel.

    Publieke proof-of-concept en aanvalsvolume

    Een werkende exploit voor Dirty Frag was publiek beschikbaar op dezelfde dag als de disclosure. De write-up van Hyunwoo Kim staat op dirtyfrag.io. Daarnaast verschijnt onder de naam “Copy Fail 2: Electric Boogaloo” een aparte publieke exploit (V4bel/dirtyfrag en 0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo) die dezelfde code-paden gebruikt en door dezelfde fix wordt geblokkeerd. Microsoft Security Response Center meldt dat post-compromise misbruik van Dirty Frag in actieve aanvallen is waargenomen.

    Wat betekent dit voor klanten van PC Patrol?

    Klanten op onze managed webhosting en managed WordPress hosting krijgen kernel-updates door ons gepland en geverifieerd, met een korte reboot-window. Op de meeste van die omgevingen draait de gepatchte kernel kort na release van de production-build van de distributie. Heb je een unmanaged Cloud VPS bij ons of elders, dan beheer je de kernel zelf en is dit het moment om patches uit te rollen of de mitigatie toe te passen.

    Wie zijn server-setup goed wil opbouwen vanaf dag één, vindt in Cloud VPS in gebruik nemen de checklist, en in Welke Linux-distributie kies je voor je VPS in 2026 de basis voor een distro-keuze die past bij jouw patch-cadans. Voor monitoring en module-state inzicht is server monitoring met Prometheus en Grafana een logische volgende stap.

    Veelgestelde vragen over Dirty Frag (CVE-2026-43284 en CVE-2026-43500)

    Heeft Dirty Frag een werkende exploit?

    Ja. Hyunwoo Kim publiceerde een PoC op dezelfde dag als de oss-security disclosure (7 mei 2026), en aanvullende publieke exploits onder de naam “Copy Fail 2: Electric Boogaloo” circuleren op GitHub. De code maakt een unprivileged shell in één enkel commando root.

    Is mijn server kwetsbaar als ik IPsec niet gebruik?

    Ja, zolang de modules esp4, esp6 of rxrpc op het systeem geladen kunnen worden. Module-autoload zorgt er normaal voor dat ze on-demand beschikbaar zijn. Daarom werkt het blacklisten van de modules zo effectief: je sluit de hele weg naar de bug af.

    Hoe snel moet ik patchen?

    Voor een kernel-LPE met publieke PoC adviseren wij binnen 24 uur te mitigeren (de modules blacklisten of de production-kernel installeren) en binnen 7 dagen op een gepatchte kernel te zitten. Voor multi-tenant hosts, container build farms, CI runners en alles waar onbekende shell-gebruikers op staan, is uren in plaats van dagen het juiste tempo.

    Wat is het verschil tussen Dirty Frag en Fragnesia?

    Dirty Frag (7 mei) en Fragnesia (13 mei) zijn aparte bugs maar leven in dezelfde code-zone (XFRM ESP en rxrpc) en gebruiken dezelfde modules om root te bereiken. De Dirty Frag-mitigatie van 7 mei (blacklist van esp4, esp6 en rxrpc) blokkeert daardoor ook Fragnesia. Wie de Dirty Frag-blacklist nog niet had toegepast, kreeg op 13 mei een tweede reden om dat alsnog te doen.

    Werkt KernelCare live patching voor Dirty Frag?

    TuxCare heeft live patches voor KernelCare-klanten uitgebracht, waarmee de kwetsbaarheid zonder reboot wordt gemitigeerd op ondersteunde kernel-versies. Voor systemen die wel direct kunnen rebooten blijft de gepatchte kernel uit de distributierepo de eenvoudigste route.

    Hulp nodig met patching of monitoring?

    Wil je kernel-patches en proactieve mitigatie volledig uit handen geven? Bekijk managed webhosting, managed WordPress hosting of plan een adviesgesprek over je VPS-beheer. Eén partner, één Nederlandse factuur, één aanspreekpunt, ook bij de volgende kernel-CVE.

    Bronnen

    Tik je bedrijfsnaam in en check de extensies.

    Eén afrekening, drie domeinen, volledige bescherming.