Dirty Frag is nieuwe bug in Linux-kernel die aanvaller rootrechten kan geven

Voor de tweede keer in korte tijd is er een grote bug naar buiten gekomen in de Linux-kernel waarmee het mogelijk is om rootrechten op een systeem te krijgen met een enkel commando. Dirty Frag misbruikt een kwetsbaarheid in een kernelfunctie die de meeste distro's gebruiken. De bug lijkt op Copy Fail, een andere recente bug.

De ontdekker van de bug zegt dat de bug uit te buiten is door twee kwetsbaarheden samen te benutten. De onderzoeker noemt de nieuwe bug Dirty Frag. De kwetsbaarheid zit in bugs in de Linux-kernel, waarmee het mogelijk is om praktisch iedere ongepatchte distro te infecteren.

Dirty Frag is een bug die het eenvoudig maakt om met één commando rootrechten op een systeem te krijgen. Het is dus een privilege-escalationbug die vooral gevaarlijk is als hij in combinatie met andere bugs wordt ingezet, of als een aanvaller al lokale toegang tot een systeem heeft.

Wat Dirty Frag extra gevaarlijk maakt, is de manier waarop de bug in de praktijk kan worden uitgebuit. Het is een deterministische bug, waarvoor het niet nodig is om een bepaalde timing te volgen en waarvoor geen race condition nodig is. Ook zegt de ontdekker dat er geen kernel panic ontstaat bij het uitvoeren van de aanval. Daardoor is het eenvoudig om de aanval met succes uit te voeren zodra een aanvaller lokale gebruikersrechten heeft.

Dirty Pipe en Copy Fail

De bug lijkt in veel opzichten op eerdere Linux-kernelbugs, specifiek Dirty Pipe uit 2022. De bug hangt samen met dezelfde kernelfunctie als Copy Fail, een kernelbug die begin deze maand uitkwam. Gebruikers die zich wilden beschermen tegen Copy Fail, konden als mitigatie algif_aead uitschakelen. Maar dat beschermt niet tegen de nieuwe bug, zegt de ontdekker van Dirty Frag. Die kan worden uitgebuit ongeacht de status van algif_aead.

Dirty Frag bestaat uit twee kwetsbaarheden, CVE-2026-43284 en CVE-2026-43500 - over die laatste is in CVE-databases nog geen informatie beschikbaar. De kwetsbaarheden zitten respectievelijk in xfrm-ESP Page-Cache Write en RxRPC Page-Cache Write in de kernel. Die eerste bug is inmiddels in de mainlinekernel gerepareerd, maar de andere nog niet.

De ontdekker zegt dat hij aan responsible disclosure deed, maar dat 'externe factoren' hem dwongen om nu de bug openbaar te maken. Met dat openbaar maken toont hij ook een proof of concept. Dat toont dat de bug in ieder geval werkt op Ubuntu, RHEL, CentOS, AlmaLinux, OpenSUSE en Fedora, maar in de praktijk lijkt iedere Linux-distro kwetsbaar. Veel populaire distro's zoals AlmaLinux hebben inmiddels een waarschuwing gegeven en testbugfixes uitgebracht.

Reacties (52)

[dvdmeer]

Ik had deze issue gemeld bij Tweakers, maar dan met nog een extra issue erbij, die hier blijkbaar niet vermeld is:
Electric Boogaloo:
https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo

[bazzi]

Mitigatie:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

[ApexAlpha]

Let wel op dat o.a. IPsec dan niet meer werkt. En andere zaken die deze module gebruiken!

[demianmonteverd]

Goede aanvulling Alex. Helaas is dit wel een serieus probleem. LPE problemen moet je zeer serieus nemen. Als je dus een tijdje zonder IPsec en AFS kan, zeker dus het advies van bazzi overwegen. En nooit commands uitvoeren die je niet begrijpt natuurlijk. Het command van bazzi word eerst root en schrijft in /etc/modprobe.d/dirtyfrag.conf het volgende weg:

install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false

En daarna verwijderd het deze zelfde modules met het rmmod commando. Een soortgelijke fix als beschikbaar was voor copy.fail, waarbij je ditzelfde kon doen voor de modules:
af_alg
algif_hash
algif_skcipher
algif_rng
algif_aead

[Olaf van der Spek]

<blockquote><div class="quote">Let wel op dat o.a. IPsec dan niet meer werkt. En andere zaken die deze module gebruiken!</div></blockquote>Welke andere zaken gebruiken deze module?

[ApexAlpha]

rxrpc wordt o.a. gebruikt in: AFS

Maar elke app die je zelf bouwt (of inkoopt) kan rxrpc gebruiken en impact ondervinden als je het uitzet.

IPSec is wel veelgebruikt en voor veel apps zal het wegvallen van IPsec betekenen dat je net zo goed de VM offline kan halen.

Dat moet elke sysadmin zelf afwegen.

[Reactie gewijzigd door ApexAlpha op 8 mei 2026 16:16]

[Olaf van der Spek]

IPSec is wel veelgebruikt

Waarvoor dan? Ik kom het voornamelijk / alleen maar tegen voor VPNs.

[Reactie gewijzigd door Olaf van der Spek op 8 mei 2026 16:20]

[ApexAlpha]

Ja dat is het ook, en als jij een VM hebt met een point-to-point IPSec tunnel naar een andere machine dan heb je dus weinig aan deze 'fix'.

Veel applicaties die zelf een tunnel opzetten doen dit ook met IPsec.

[jumbos7]

De toevoeging voor IPSec en AFS gebruikers is belangrijk, al denk ik wel dat de doorsnee Linux-gebruiker thuis die zelf de sysadmin is de mitigatie bijna altijd kan gebruiken. De meeste VPN-verbindingen zullen gaan over OpenVPN of Wireguard en wie IPSec of AFS gebruikt zal dat vaak weten. Maar als je de enige gebruiker bent van je systeem ben je niet heel kwetsbaar en kun je prima wachten tot de kernel is gepatched.

[demianmonteverd]

Ben eigenlijk wel benieuwd of iemand hier AFS gebruikt nu.

[TheDevilOnLine]

Precies dit is een reden waarom het geen +3 zou moeten krijgen!

[pjottum]

Let op: als je de mitigatie van @bazzi niet zelf kan lezen copy&paste dit soort dingen dan niet direct in je systemen. Ik weet ff niet wat de esp4 esp6 en rxrpc modules doen dus de vraag is of je die wel zomaar uit je kernel kan laden.

(verder: bronvermelding is aardig @bazzi (https://access.redhat.com/solutions/7142250) en thanks for sharing denk ik.)

[Wessel de NERD]

Dit commando is afkomstig van https://github.com/V4bel/dirtyfrag#mitigation, met sudo vooraf toegevoegd zodat het werkt vanaf een gebruikersshell.
De syntax is onnodig omslachtig om het een one-liner te maken en het rmmod commando gebruikt 2>/dev/null om errors overbodig te surpressen.
Wat het doet is de esp4, esp6 en rxrpc kernel modules volledig uitschakelen.
De install [module] /bin/false commando's zijn soort van correct, omdat dit het laden als depenency van andere modules voorkomt.
Maar het zou ook gecombineerd moeten worden met de normale blacklist syntax.
Zie https://access.redhat.com/solutions/41278 voor goede uitleg en volledige stappen.
De rmmod en modprobe -r commandp's zijn functioneel identiek.

[Reactie gewijzigd door Wessel de NERD op 8 mei 2026 16:06]

[HollowGamer]

Precies, je moet ook rebooten na een blacklist.

[TheDevilOnLine]

Als je mensen dan wilt helpen, vermeldt dan ook even een bron of uitleg wat je commando doet. Ik ga er in ieder geval vanuit dat een beetje tweaker niet zomaar een sudo commando copy-paste.

[arjankoole]

een beetje tweaker met linux systemen onder z'n vingers, weet wat dat commando doet.

overigens is op mijn ubuntu machines deze module niet standaard geladen, een blacklist doet 't ook.

blacklist werkt niet voor insmod, maar maar daarvoor moet je root zijn en dan heb je de hack niet nodig.

[Grabbels]

Ik denk dat nog niet eens 10% van de Tweakers die Linux gebruiken zomaar deze command weten te lezen en te begrijpen, maar dat is dan weer mijn assumptie, dus laten we assumpties achterwege laten en er niet van uit gaan dat command line commando’s gewoon altijd van tekst en uitleg voorzien moeten worden zodat onwetende mensen het kunnen leren te begrijpen.

[Reactie gewijzigd door Grabbels op 8 mei 2026 16:55]

[demianmonteverd]

Denk dat dat wel mee zal vallen. En anders kunnen ze deze kans gebruiken om meer te leren natuurlijk.

[Grabbels]

Wederom een aanname. Zonder tekst en uitleg bij een commando wordt er dus niet geleerd.

Ik gebruik al 15 jaar Linux, en heb een commando als deze niet eerder bewust nodig gehad en heb dus nooit de kans gehad te weten wat het doet. Op Linux kom je vaak een heel eind met een set basiscommando’s om de boel draaiende te houden.

[Reactie gewijzigd door Grabbels op 8 mei 2026 16:57]

[demianmonteverd]

Als iemand iets post met uitleg, kun je toch beter zelf uitzoeken wat het doet. Ik elders hier uitgewerkt wat het commando doet, maar bijv. de rol van printf heb ik overgeslagen (net als 2>/dev/null ; dat eigenlijk niet in het commando had moeten staan m.i., maar dit terzijde). Het beste is altijd om zelf uit te zoeken wat iets doet. Dat is meer werk, zeker in dit geval omdat je dan best veel moet doornemen om uit te zoeken wat modprobe.d configs doen, etc., maar uiteindelijk leer je er wel iets van. Uit je reactie waarmee je reageerde maakte ik overigens niet op dat je nog niet wist wat dit command deed.

[HollowGamer]

Drie kwart weet niet hoe een journal werkt, kent dmesg of heeft zelfs al eens een package gebuild.

Ik zou echt mensen sterk afraden dit commando te plakken (zelfde met copyflow), en te wachten op je distro upgrade. De meeste hadden dit dezelfde dag al gepatched.

[tszcheetah]

Vergeet niet om, mocht je al aangevallen zijn of zelf de exploit hebben gedraaid, ook de page caches te flushen (bron):

echo 3 > /proc/sys/vm/drop_caches

Een reboot werkt natuurlijk ook.

[demianmonteverd]

Prima aanvulling. Je kunt er nog bijschrijven dat dit advies word gegeven omdat je machine anders onstabiel kan worden.

[HollowGamer]

Je moet ook herstarten. Naar mijn weten doet rmmod enkel een module unload, maar het script kan deze dus zelf weer opstarten (modprobe esp4) of iets triggeren waardoor die module weer wordt opgestart.

[demianmonteverd]

Zijn er distro's waar een lokale user modprobe kan doen eigenlijk? Vast wel, maar welke zijn dat?

[HollowGamer]

Het kan ook een service zijn, met die rechten. Bijvoorbeeld OpenVPN.

[Zezura]

Aan alle andere tweakers, NOOIT zomaar commando's uitvoeren zonder het zelf te begrijpen. Ook al is je mede-tweaker een goede behulpzaam persoon.

Als je het niet begrijpt NIET DOEN!

[armageddon_2k1]

Welke externe factoren dwingen je een bug openbaar te maken....

[locke960]

https://github.com/V4bel/dirtyfrag:
Because the embargo has currently been broken, no patch or CVE exists. After consultation with the maintainers on [e-mail] and at their request, this Dirty Frag document is being published. For the disclosure timeline, refer to the technical details.

[Groentjuh]

Ik heb ergens gehoord dat via patches, die publiek werden, deze exploit ook door andere werd gevonden. Daarom werd gekozen om deze exploit nu al te publiceren.

Dit kun je ook terugzien in de timeline in de Dirty Frag-repo:

2026-05-07: Submitted detailed information about the vulnerability and the exploit to the linux-distros mailing list. The embargo was set to 5 days, with an agreement that if a third party publishes the exploit on the internet during the embargo period, the Dirty Frag exploit would be published publicly.

2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.

2026-05-07: After obtaining agreement from distribution maintainers to fully disclose Dirty Frag, the entire Dirty Frag document was published.

[tszcheetah]

De kwetsbaarheid werd door iemand anders ook gevonden en de info was al gepubliceerd. Waarschijnlijk gaat het om deze post. Dit is buiten het embargo om gegaan (daar had deze persoon niks mee te maken). Het is gedaan op basis van analyse van (openbare) commits op de Linux kernel. Na publicatie daarvan is dus besloten om de hele info vrij te geven - die lag toch al op straat.

[Reactie gewijzigd door tszcheetah op 8 mei 2026 16:12]

[Blonde Tux]

Gokje: Linus reageerde misschien niet zoals hij gehoopt had. Mr. Torvalds heeft de naam nogal hoekig in communicatie te zijn.

[HollowGamer]

YouTube: New Linux Exploit Just Dropped (Before the Fix)

Ik raad hem echt aan te volgen. Hij legt dingen goed en technisch uit. Waarbij andere vooral het dramatisch/klikbaar houden, is hij meer van de achtergrond.

Volgens mij komt het doordat iemand de commit heeft gezien, en die is gaan reversen. Een andere versie is dat het op een openbaar chat kanaal was gedeeld..

Geen idee welke van de twee correct is. Had liever gezien dat er nog even 5 dagen waren gewacht, maar wel al was gecommuniceerd naar distros. Aan de andere kant moet je ook open zijn.

[Blonde Tux]

Nou dat worden wel wat overuurtjes komende week voor veel systeembeheerders als nog voor het weekend een patch komt.

[VriendP2]

Fijn, zo vlak voor het weekend.

[Brummetje]

Dit was vannacht inderdaad naar buiten gebracht dus wij hebben vanmorgen direct al onze servers ge-hotfixt. Deze waren inderdaad bijna allemaal vatbaar voor de exploit met 1 simpel commando.

[Speeder]

Tweede CVE is nog pending. Mitigatie is het handmatig niet laden van de getroffen kernel modules ESP4, ESP6 en RxRPC. Maar als ik het goed begrijp heb je wel eerst een local user nodig voor dat je deze bugs dus kan misbruiken.

[HollowGamer]

Je kan dit krijgen door bijvoorbeeld een webserver te misbruiken. De meeste processen draaien onder een user tegenwoordig, maar helaas doen de meeste nog altijd dat draaien onder admin, en geven die ook sudo rechten of laten su toe.

Ik dacht dat het ook werkte in een container, als je lokaal account maar een root process kan opstarten.

[Speeder]

Ja, las bij Ubuntu dat het ook met containers werkte. https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available

[HollowGamer]

Er staat may bij, maar inderdaad kan je er wel van uitgaan. Containers zijn helaas niet bulletproof.

Hopelijk worden de fixes snel gepushed en servers snel geupdate.

[Speeder]

Dat hoop ik ook.

[Pinkys Brain]

Standaard containers, maar er is dan ook het gezegde dat "containers don't contain". Met gvisor en kata containers is er geen escape.

[kdekker]

Elke software bevat lekken. Zorg gewoon dat je netwerksegmentatie hebt, aan de voordeur een goede bescherming en gebruikersbeheer. Normaal gesproken zijn interne systemen (afgezien wat in je DMZ zit) niet toegankelijk van buiten. Dus deze bug is pas een probleem 'als er al een inbreker binnen is'. Of, en dat is misschien realistischer, een medewerker die toegang tot het systeem heeft, met lokale rechten, en effe irritant wil doen. Dat laatste heb ik nooit meegemaakt.

Uit de tijd dat ik heel veel met Linux werkte: lokale gebruikers (developers), die iets te zoeken hadden om het systeem, hadden (vaak) al root rechten (anders kon je je development werk niet goed doen). En medewerkers die niets te zoeken hadden op het systeem, hadden geen toegang. Incl. je manager, die geen toegang had, omdat die niets te zoeken had .

[MneoreJ]

Je denkt teveel in termen van mensen, en te weinig in termen van defense in depth. Wat te denken van non-root processen die op het systeem draaien en die invoer van buiten moeten accepteren? Stel dat daar een kwetsbaarheid a la buffer overflow in zit -- dat is natuurlijk op zichzelf kwalijk, maar met dit erbovenop is dat gelijk ook root toegang tot het systeem, wat je dan weer kan gebruiken om auditing te ondergraven, en van het hele systeem een gevaarlijke berenval te maken voor mensen die willen kijken wat er mis is.

En nee, gescheiden netwerken en DMZ's dekken zulke dingen niet volledig af -- als je systemen wat nuttigs moeten doen voor de buitenwereld is het per definitie altijd mogelijk om invoer van buiten naar binnen te krijgen (want nodig), hoeveel laagjes bescherming er ook tussen zitten.

[kdekker]

Input validatie is anno 2026 toch wel gemeengoed?

[Ninaomi]

AlmaLinux Fix/Patch

https://almalinux.org/blog/2026-05-07-dirty-frag/

[Zwippet]

Ik draai meerdere Proxmox servers in mijn thuis omgeving voor domotica. Loop ik hiermee gevaar of kan ik wachten en later updates uitvoeren? Kan dat niet inschatten.

[HollowGamer]

Het ligt eraan welke domotica, hoe je het draait en of je nog andere gekken dingen doet.

Als je als user geen gekke dingen doet (dus geen random scripts uitvoert) en let op wat je doet, is de kans vrij klein. Toch is het beste dit z.s.m. te patchen door de distro zelf en voorzichtig te zijn met een nieuw fenomeen (wat ik alvast voorspel): mensen die een random script aanraden/commando's, om ervan af te komen (en je daarmee juist met malware injecteren).

[Zebby]

Men moet toegang hebben tot je server met een user om dit (en de vorige) uit te kunnen voeren. Zolang jij je servers potdicht hebt staan voor de buitenwereld is er niks aan de hand, of in ieder geval geen spoed.

[demianmonteverd]

Kan men van buiten iets doen dat bij machine kan? Of haal je data binnen en verwerk je dat? Dan kun je overwegen dit dicht te zetten op de manier die bazzi deelde.

Ik ga alles wel dicht zetten, ik gebruik die kernel modules sowieso niet (laatste keer dat ik iets met ipsec deed was acht jaar terug), dus er gaat voor mij niets verloren.