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 (49)

[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]

[HollowGamer]

Opzicht ook positief, gelukkig komen deze upstream terecht en niet in de darknet.

Hopelijk worden updates z.s.m. uitgevoerd. System admins zijn niet zo happig op updates (generaliserend gezegd): 'Een nieuwe kernel update? Nee, te veel gedoe - we blokkeren de modules wel.'

Je kunt beide gewoon doen. Dan heb je een fix voor de exploits (dus ook openssh upgraden) en je schakelt onnodige modules/settings uit. Helaas gok ik dat veel eigenwijs zijn, en echt alleen het laatste doen (want nieuw - breekt altijd iets gedachte). Dit zie je vooral terug in de Debian mindset, waar zeker iets voor te zeggen is, maar misschien containers en VMs beter opties/toevoegingen kunnen zijn..

[Reactie gewijzigd door HollowGamer op 15 mei 2026 12:52]

[Zezura]

Nah, in mijn homelab doe ik liever

~ Apt upgrade.

Enige vervelende vind ik het overgaan naar een nieuwe versie van de distro, zoals naar Trixie. Daar houdt ik wel vaak mijn hart bij vast. Op zo’n moment kies ik er vaak voor om de setup opnieuw te installeren.

[himlims_]

De stappen goed volgen, mits geen rare configuratie gaat dat prima. Heb bakken gehad die van 8>9>10 etc zijn gegaan. Debian is best solide daar in

[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.

[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.

[Transportman]

Maar wat gaat dat op termijn voor projecten betekenen? Hoe gaan we maintainers gemotiveerd houden om betrokken te blijven als alle code toch door AI geschreven wordt? Nieuwe mensen trekken om projecten te ondersteunen? Ik denk dat heel veel projecten, zowel OSS als closed source bedrijven, het deksel nog wel op de neus gaan krijgen als ze nu vol op AI gaan inzetten.

[dutchruler]

Waarom zou je maintainers gemotiveerd willen houden als het toch door AI wordt gedaan.
De enige afweging zou moeten zijn. Zijn maintainers kwalitatief nog steeds beter dan AI. Zodra dit nee is kan je die maintainer tak wel afhakken.

Ik denk dat er wel nog een kleine groep over zal blijven als gatekeeper's om te zorgen dat er niet te veel rare dingen gebeuren, maar dit zal nog maar een fractie zijn van de mensen die nu nodig zijn.

Opensource zal ook gaan veranderen hierdoor, want de AI kan toch vrijwel alles depersonalized maken voor de klant.

[Iced Maggot]

Daar zou ik nou niet zo blind op vertrouwen, zoals je stelt.

Goed dat je uw code hebt nagelopen. Review is mijn inziens altijd nodig. Je gaat zoiets toch niet blindelings inchecken en naar productie omgeving brengen.

[dutchruler]

Het gaat hier om in-house software en wordt gecoverd met unit tests en SIT tests.
En ja uiteraard kijk ik het wel na, maar de software is nu al veel te complex om dat puur handmatig te doen.

Je praat over meer dan een miljoen regels code.

[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.

[dasiro]

Niemand verplicht je om software opensource te maken tenzij je er zelf voor kiest, bvb door andere OSS software te gebruiken. Als je iets met de wereld deelt, dan is het logisch dat de wereld er ook op reageert.

[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.

[SunnieNL]

Dat punt en die tools bestaan al even. Die worden ook geüpdatet en uitgebreid met dezelfde llm van de tools die deze gaten vinden.

Of iedereen er voor wilt betalen is een ander ding.

Testen verschuift ook deels naar developers. Die doe de tests eerst op feature niveau. Software Testers en security testers doen dat vervolgens op het gehele product.

[Reactie gewijzigd door SunnieNL op 15 mei 2026 12:35]

[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.

[slowdive]

Voor de toekomst betekend dat dat developers security echt serieus moeten gaan nemen, eventueel ondersteund door ai. Anders doen onethische hackers dat wel (niet in de toekomst, maar nu).

"Security first" lijkt me een gepast credo voor developers. Functionaliteit is dus ondergeschikt aan veiligheid. Voor fysieke tools vinden we dat overigens heel gewoon.

Niemand wil geëlektrocuteerd worden door de broodrooster, hoe lekker de toast ook is.

[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.

[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

[readefries]

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

[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.

[Webgnome]

is het niet mogelijk om via via alsnog toegang te krijgen. Stel je hebt een nodejs omgeving en tijdens deploy worden packages geinstalleerd waarbij in 1 van de packages code zit die op de cli moet worden uitgevoerd dan zou het theoretisch toch kunnen om hier misbruik van te maken?

[Defspace]

Zeker, als jij zelf (onbewust) malware code uitvoert dan ben je vatbaar. Sowieso zo snel mogelijk patchen dus of die modules uitschakelen.

[Dreamvoid]

Je kan er tegenwoordig beter van uit gaan dat er minstens 1 apparaat op je lokale netwerk al deel is van een botnet. Een televisie, een telefoon, een speaker, een router, etc.

Het idee dat je achter een firewall veilig bent is al jaren achterhaald.

[Reactie gewijzigd door Dreamvoid op 15 mei 2026 12:50]

[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]

[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?

[Delishizu]

Klopt, de modules esp4 en esp6 worden gebruikt voor IPsec dus als je dat niet gebruikt worden ze niet geladen.

[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

[nielsdc]

Dit is geen logic-bug in het ESP-in-TCP-subsysteem, maar een bug in de netwerk core (skb_try_coalesce). Die verwijderd de shared frag vlag in sommige gevallen. ESP-in-TCP checkt die vlag en doet een in place decrypt als de vlag niet gezet is.