Onderzoekers vinden derde vergelijkbare Linux-kernelbug in maand tijd

Opnieuw is er een bug ontdekt in de Linux-kernel die het mogelijk maakt ongeoorloofd adminrechten te krijgen op een systeem. Fragnesia, zoals de bug wordt genoemd, lijkt op Dirty Frag en Copy Fail, die eerder deze maand uitkwamen. Fragnesia treft dezelfde kernelmodules. Eerdere Dirty Frag-patches werken niet, maar mitigaties wel.

Dit nieuws in het kort

• Fragnesia is een bug die vrijwel alle Linux-distro's treft.
• Met Fragnesia is het mogelijk rootrechten te verkrijgen.
• De bug lijkt op Dirty Frag en Copy Fail, die eerder deze maand uitkwamen.
• Dezelfde mitigatie voor Dirty Frag werkt ook voor Fragnesia.

De bug wordt Fragnesia genoemd door de onderzoekers van V12, een securitybedrijf dat AI-agents gebruikt om kwetsbaarheden te vinden. De bug wordt getrackt als CVE-2026-46300.

Met de bug is het mogelijk rechten te verhogen. Een aanvaller die als gewone gebruiker op een systeem zit, kan er eenvoudig rootrechten mee krijgen. Het gaat om een logic-bug in het ESP-in-TCP-subsysteem van de Linux-kernel die het mogelijk maakt willekeurige bytes te schrijven naar een cache van wat normaal gesproken alleen-lezen-bestanden horen te zijn. Daardoor is het mogelijk het cachegeheugen te corrumperen en een shell met roottoegang te krijgen. Daarbij is, net als bij eerdere kernelexploits, geen race condition nodig.

De ontdekkers hebben een proof-of-concept online gezet, waardoor het relatief eenvoudig is de bug praktisch uit te buiten. Enigszins opvallend is dat de ontdekkers niet schrijven hoe hun responsible-disclosureproces is gelopen, en gezien de link met eerdere bugs lijkt het erop dat de bug pas recent is ontdekt en OS-makers dus weinig tijd kunnen hebben gehad om de bug te repareren. De bug treft vrijwel alle distro's, waarvan veel zoals Ubuntu en AlmaLinux inmiddels eigen blogs hebben schreven en in sommige gevallen alsnog een patch hebben doorgevoerd.

De bug is niet los te zien van Dirty Frag, een kernelbug die eerder deze maand in het nieuws kwam. Er zijn een paar verschillen; zo bestaat Dirty Frag uit twee verschillende bugs die aan elkaar moeten worden geregen en is Fragnesia slechts één bug. Tegelijkertijd zeggen de makers dat de bugs dezelfde kernelprocessen treffen.

Daardoor is dezelfde mitigatie als die voor Dirty Frag ook van toepassing op Fragnesia. Gebruikers die esp4, esp6 en rxrpc uitschakelen, zijn niet kwetsbaar. Volgens de ontdekkers zijn verder alle kernelversies kwetsbaar die vóór 13 mei van dit jaar uitkwamen.

Reacties (25)

[Erwin1985]

Dit is een serieus goede use-case voor AI agents. De source code bases van sommige projecten is zo groot geworden (net als het verloop van programmeurs) dat niemand meer als 1 persoon de code "in zijn hoofd heeft". LLM (?) modellen die een geavanceerde versie van static analysis doen kunnen een vervanging zijn hiervoor.

Voor wie geen c programmeur is: https://www.google.com/search?q=c+static+analysis

[Reactie gewijzigd door Erwin1985 op 15 mei 2026 10:46]

[MrFax]

Het nadeel van het bestaan van deze AI agents is wel dat het vinden van kwetsbaarheden heel veel last legt op de developers van al deze open source software, want AI agents zijn beter in het vinden van kwetsbaarheden dan het (bugvrij) dichten van kwetsbaarheden, en daardoor moet de software wel eerst weer volledig getest worden na zo'n fix. Dit kan niet volledig door AI worden overgenomen, wat zorgt voor een enorme druk op developers en testers.

[Reactie gewijzigd door MrFax op 15 mei 2026 11:07]

[MueR]

Om nog maar te zwijgen van alle "security researchers" die talloze PRs op je afschieten met LLM generated onzin, waar jij als maintainer tijd aan moet spenderen.

[FreezeXJ]

What is created by LLM can be handled by LLM.

Keurig laten analyseren door een eigen agent, en alleen als die er iets in ziet gaat een mens er tijd aan besteden. Anders autoreply 'our AI decided your AI sucks', en klaar.

[dutchruler]

Jou job als 'maintainer' gaat sowieso veranderen. Dat gaat binnenkort echt niet meer met de hand.
Het wordt een kwestie van agent <--> agent in een vrijwel closed loop om de software zo te optimaliseren en efficient te maken dat jij als maintainer or developer de code straks vrijwel niet meer kan herkennen.

Ik zie dat in mijn eigen projecten al waar de AI dagen bezig is met 200k regels aangepast. En ja ik heb het nagelopen en het is stukken beter dan als ik het zelf had gedaan.

[Eusebius]

Komen we op een gegeven moment niet op een punt dat je nieuwe code eerst door een LLM haalt en voor publicatie / bij beta al op mogelijke fouten wordt gewezen? Net zoals een spell checker in Word je allerlei suggesties geeft en je woorden kunt negeren, toevoegen of verbeteren.

[david-v]

Tja, hoe minder je test hoe minder bugs je gaat vinden. Als je teveel test krijgt je developers team het heel druk met bugs oplossen. Dit is niet anders maar dan security bugs. Ik zie het niet als een nadeel maar juist als een wakeup call dat er meer gedaan moet worden aan security bugs, anders blijven we achter de feiten lopen. Als je test straat goed is ingericht met unittests, regressietesten, statische en dynamische code tests dan heb je een stuk minder handmatig testwerk. AI kan niet alleen de bugs vinden maar ook suggesties geven voor het oplossen hiervan. AI eenzijdig inzetten, of het nou voor coderen is of voor het vinden van (security) bugs lijkt me geen goeie strategie.

[blackSP]

Noblesse oblige.

Als jij, of je team/bedrijf de (te grote/complexe) code base niet volledig onder controle hebt en AI, of een persoon, kwetsbaarheden ontdekt zal je aan de bak moeten. Feature dev stop, probleem oplossen. Klinkt makkelijker gezegd dan gedaan natuurlijk maar ik ben als C programmeur ondertussen blij met AI als co-developer, bug en leak finder en fixer. Ik gebruik een mix van Gemini 3.1 Pro, Qwen 3.6 lokaal en eventueel een derde model om AI fixes te valideren waarna ik alles test, overgebleven of issues analyseer, oplossingen bedenk en de resultaten weer door m'n AI proces haal.

[fedaykin]

Ik heb me niet heel ver ingelezen in de technieken achter deze vunerabilities, weet een low level tweaker of dit soort problemen vaker opgelost kunnen worden met stukken kritieke code over te brengen naar Rust?

[Stetsed]

Hey, lokale linux/rust tweaker.

Nee, de meeste van dit soort bugs zouden niet zijn opgelost omdat ze geen memory bugs zijn, maar logic bugs. Dit betekent dat het niet zoals veel exploits die je ziet en die rust voorkomt bijvoorbeeld buffer-overflow, maar dat het gewoon puur de logica is die fout is. (Dit geldt teminste voor Copy Fail en Dirty Frag, ik heb me nog niet ingelezen naar deze exploit).

Rust kan dit soort dingen ook niet voorkomen, dat kan geen enkele taal eigenlijk. Het is eigenlijk alsof je in een web app de hele database opvraagt en die aan de user laat zien, het maakt niet uit in welke taal je het doet, als de logica hetzelfde is zal het dezelfde problemen hebben.

Dit is ook waarom ze zo gevaarlijk zijn, want het is vaak niet nodig zoals met veel memory vulnerabilities dat je de kans loopt wanneer je in de kernel speelt dat je de machine bijvoorbeeld crasht. Wat het veel makelijker maakt om onbekend te blijven. En het betekent ook dat ze veel consistenter zijn

[Reactie gewijzigd door Stetsed op 15 mei 2026 10:59]

[zenlord]

Geen idee of deze problemen zich met Rust niet zouden stellen, maar het ziet er naar uit dat SE Linux aanzetten minstens 3 van de 4 deze maand gerapporteerde vulnerabilities onklaar zou maken: https://etbe.coker.com.au/2026/05/15/debian-selinux-ssh-keysign-pwn/ (minstens op Debian Trixie)

Of Mythos nu eerder mythe is of ons werkelijk schrik moet doen krijgen, laat ik in het midden, maar ik heb alvast beslist om SE Linux op al m'n servers te implementeren.

[Scribe]

Net voordat ik las zag ik bij Phoronix dat er weer een nieuwe vulnerability bijgekomen is... Mythos draait overuren

[d3vlin]

Voor de liefhebbers ook gelijk de vierde:
https://www.phoronix.com/news/Linux-ssh-keysign-pwn

[Reactie gewijzigd door d3vlin op 15 mei 2026 11:11]

[witteveder]

Ik voorzie een wapenwedloop voor het inzetten van AI tools om bugs in software te vinden. Aan de ene kant staan de onderzoekers die bugs zoeken om zo software zo veilig mogelijk te maken en aan de andere kant de 'onderzoekers' die deze bugs willen ontdekken en exploiteren voor allerlei vervelende doeleinden.

[keejoz]

Het artikel hier spreekt over Ubuntu, maar andere bronnen (oa Reddit) zeggen dat Ubuntu en Debian niet standaard kwetsbaar zijn vanwege AppArmor.


Uiteraard snap ik dat als Ubuntu dit zelf op hun website deelt dat het waarschijnlijk wel het geval is, maar toch vind ik het bizar.

[Reactie gewijzigd door keejoz op 15 mei 2026 10:51]

[theduke1989]

wij zijn ook druk bezig met patchen van de kernel op Oracle10.

SecOPS had zelfs op een vrije dag dit aan onz toegewezen, Rapid7 toonde dit direct aan!! nja patchen is het nieuwe werken bij de sys administratoren!

[Reactie gewijzigd door theduke1989 op 15 mei 2026 10:58]

[Tralapo]

De blog van Ubuntu beschrijft een methode om de modules uit te schakelen en daarna een check of ze nog geladen zijn. Ik heb die check als eerste uitgevoerd op mijn Ubuntu Servers en ze geven allemaal aan NOT LOADED, zonder de modificatie. Standaard lijken deze dus al niet geactiveerd te zijn?

[Grompoe]

Is er fysieke toegang nodig of kan dit ook op afstand worden uitgevoerd?
Nu net 2 weken op Linux dus ben nog zoekende hoe alles werkt. Maar CachyOS heeft dagelijks updates dus dat werkt wel fijn

[Goldwing1973]

Op het moment dat je SSH open zet naar het internet en je iemand een account heb gegeven zodat die kan inloggen via SSH, dan zou iemand remote deze exploit kunnen gebruiken.

Staat je PC gewoon achter de router zonder open poorten naar het internet hoef je je geen zorgen te maken.

[marktweakt]

Het is een 'privilege escalation' exploit waardoor je eerst al toegang moet hebben tot het systeem. Dat kan lokaal of remote zijn denk ik.

[Nickname55]

Zoals de anderen al schrijven: het kan via SSH toegang. Maar als je dat niet ingeschakeld hebt, of je hebt geen poorten open gezet in je router, dan zit je veilig. Waarschijnlijk staat de SSH server op CachyOS standaard uit.

Verder: voer geen scripts of commando's uit vanuit onbekende bron. Dat is sowieso nooit verstandig. Maar met zulke bugs al helemaal niet.

[Reactie gewijzigd door Nickname55 op 15 mei 2026 11:24]

[readefries]

Dit is ook een local privilege escalation, net als de andere twee.

[Whiskeyjack]

kijk, dit soort sores heb je niet in een goed georganiseerd ontwikkeld systeem zoals Windows. Geef het toch op mensen. Het is niks en het wordt niks, voor consumenten.

[maurict]

Bij Linux komen worden deze ontdekkingen mede gedaan omdat het open-source is (en AI modellen goed zijn in code scannen).

Mijn verwachting is dat binnen geringe tijd ook grote (en mogelijk nog veel ernstigere) problemen in Windows gevonden gaan worden d.m.v. AI. Het duurt alleen wat langer omdat het closed-source is. Tegen die tijd zijn de grootste problemen in Linux al lang opgelost

[segil]

Onlangs was ook Electric Boogaloo in het nieuws gekomen

Electric Boogaloo maakt het mogelijk om de page-cache van elk leesbaar bestand te overschrijven. Bij de proof-of-concept exploit die van het lek misbruik maakt wordt een vermelding in /etc/passwd overschreven en voorzien van een nieuwe gebruiker met rootrechten, waarna er als deze gebruiker wordt ingelogd. Het is een soortgelijke kwetsbaarheid als het Copy Fail-lek, maar bevindt zich in een ander subsysteem, zo laat het beveiligingsbulletin weten. De exploit is getest tegen verschillende versies van Ubuntu, Debian, Archc en Fedora. In het bulletin wordt geen melding gemaakt van de beschikbaarheid van patches.

https://www.security.nl/p...aakt%3A+Electric+Boogaloo