B—OPSOFFSEC / EU
Copy Fail verdient aandacht omdat deze Linux-bug eenvoudig, draagbaar en op precies de verkeerde manier saai is. Geen race condition. Geen heap feng shui. Geen distro-specifieke acrobatiek. Als een aanvaller al code kan uitvoeren als niet-geprivilegieerde gebruiker op de host, kan die foothold vaak met heel weinig frictie naar root worden omgezet.
Eerst de kern
Dit is geen initial-access-kwetsbaarheid. Copy Fail geeft een internetaanvaller niet zomaar code-uitvoering uit het niets. Het zet lokale code-uitvoering om naar root. Dat onderscheid doet ertoe. Als niemand code op de host kan uitvoeren, doet deze bug op zichzelf niets.
De patchprioriteit hangt af van gedeelde compute. Als je Kubernetes-nodes, self-hosted CI-runners, jump boxes, notebookplatformen, shellservers of andere omgevingen draait waar minder vertrouwde gebruikers, containers of jobs een kernel delen, behandel dit dan als urgent. In zulke omgevingen ligt "gewone gebruiker" dicht genoeg bij "root" tot de patch erop staat.
Single-tenant Linux blijft wel degelijk geraakt. Het verschil is operationeel, niet technisch. Op een klassieke productieserver is dit meestal de tweede stap van een compromise: web-RCE, een gestolen SSH-credential of een gecompromitteerd service-account wordt root op de host. Dat is nog altijd ernstig. Het is alleen niet hetzelfde als een remote pre-auth inbraak.
Er is een tijdelijke mitigatie beschikbaar. Als je meteen de patch- en containmentstappen wilt, spring dan naar de remediatie. De korte versie is eenvoudig: installeer de vendor-fixed kernel en reboot daar effectief in. Als die update nog niet beschikbaar is, schakel dan algif_aead uit, unload de module als ze al geladen is, en blokkeer AF_ALG-socketcreatie voor minder vertrouwde workloads.
Waarom deze bug ertoe doet
Lokale privilege escalations op Linux zijn op zich niet zeldzaam. Exemplaren die betrouwbaar blijven over distrogrenzen heen zijn dat wel. Copy Fail springt eruit omdat het exploitpad rechtlijnige logica is: dezelfde publieke proof of concept is getoond op Ubuntu, Amazon Linux, RHEL en SUSE zonder per-target aanpassingen, zonder retries en zonder timingtrucs.
Dat is vooral relevant in omgevingen die aanvaller-gecontroleerde code per ontwerp al uitvoeren. Denk aan pull-request-runners, vijandige multi-tenant workloads, labshells, data-science-notebooks of containerplatformen waar de tenantgrens bij de kernel stopt. In die gevallen is de ontbrekende voorwaarde niet "kan er code draaien?" maar "kan er code draaien zonder al root te zijn?" Copy Fail beantwoordt precies die laatste vraag.
Het is ook stealthier dan veel teams verwachten. De primitive richt zich op de page cache, niet op het bestand op disk. Een gewone checksumcontrole op de binary op schijf kan dus schoon terugkomen terwijl het in-memory image dat de kernel werkelijk uitvoert al aangepast is.
Wat deze bug werkelijk is
De kwetsbare keten zit op het snijpunt van drie kernel-features die elk op zichzelf redelijk leken. Eerst exposeert AF_ALG delen van het crypto-subsystem van de kernel aan niet-geprivilegieerde user space. Daarna kan splice() file-backed pages per referentie verplaatsen in plaats van ze te kopieren. Ten slotte maakte een optimalisatie uit 2017 in algif_aead een AEAD-pad in-place.
Op papier klinkt dat als interne plumbing. In de praktijk betekent het dat een aanvaller de page-cache-pagina's van een leesbaar bestand in een AEAD-request kan voeren en diezelfde pagina's vervolgens kan laten opduiken in een scatterlist die de kernel later als schrijfbare destination memory behandelt.
Het algoritme dat van die ontwerpfout een exploit maakt is authencesn, een AEAD-wrapper voor IPsec Extended Sequence Number-support. Het decrypt-pad gebruikt destination memory als scratchruimte en schrijft vier bytes voorbij de geldige outputgrens. Onder normale aannames hoort dat in wegwerpbufferruimte terecht te komen. In het in-place AF_ALG-pad kan het in de page cache van het gesplice-te bestand landen.
Hoe de write buiten de buffer terechtkomt
Het kernidee is onaangenaam proper. De aanvaller splicet een leesbaar doelbestand naar een pipe en van die pipe naar een AF_ALG-AEAD-socket. Omdat splice() pagina's per referentie doorgeeft, werkt de kernel dan op de gecachete pagina's van het doelbestand in plaats van op een gekopieerde user buffer.
In het kwetsbare in-place decrypt-pad bouwt algif_aead een gecombineerde scatterlist op: eerst een normale receive buffer, daarna chained tag pages die nog altijd naar de page cache wijzen. authencesn voert daarna zijn scratch write uit op offset assoclen + cryptlen, die al buiten de legitieme plaintext-outputregio valt. Zodra die offset buiten de receive buffer schuift, landt de volgende write in de chained page-cache-pages.
De write is maar vier bytes groot, maar dat is genoeg. Uit het publieke onderzoek blijkt dat die vier bytes door de aanvaller te sturen zijn, dat de doelfoffset controleerbaar is, en dat de write overleeft zelfs als de cryptografische operatie zelf faalt. De kernel markeert het onderliggende bestand nooit dirty voor writeback, waardoor het diskimage ongewijzigd blijft terwijl de in-memory cached copy ondertussen anders is.
Daarom is deze bug zo bruikbaar tegen setuid-binaries. Je hebt geen persistentie in het bestandssysteem nodig. Een enkele succesvolle uitvoering van het aangepaste cached image volstaat.
Hoe dit is ontdekt
Copy Fail werd op 29 april 2026 openbaar gemaakt door onderzoekers van Theori en Xint. Het interessante is niet alleen dat AI betrokken was, maar hoe. Het vertrekpunt was een menselijke onderzoeksintuïtie van Taeyang Lee: AF_ALG plus splice() creëert een ongebruikelijk pad waarin niet-geprivilegieerde user space page-cache-backed data rechtstreeks in het crypto-subsystem van de kernel kan voeren.
Van daaruit werd Xint Code gebruikt om het Linux-crypto/-subsystem door te lichten op vanuit user space bereikbare paden die aannames rond scatterlists en schrijfbare buffers schenden. Volgens de onderzoekers kwam Copy Fail in ongeveer een uur scantijd naar boven als de zwaarste finding. Dat is ook voor verdedigers een nuttige reminder: AI wordt beter in het helpen van ervaren onderzoekers om een vermoeden op te schalen tot een echte bugklasse. Het vervangt expertise niet. Het versnelt ze.
Gesaneerde PoC-flow
De publieke exploit is al beschikbaar, maar wij reproduceren hier niet de werkende one-liner. Voor verdedigers is het belangrijkste dat de exploitketen kort, voorspelbaar en makkelijk te doorgronden is:
open(readable_setuid_binary)
splice(file_pages -> pipe)
splice(pipe -> AF_ALG_aead_request)
trigger_vulnerable_in_place_decrypt()
repeat_controlled_4_byte_writes()
execve(modified_cached_setuid_binary)De publieke PoC zou standaard /usr/bin/su gebruiken omdat dat op de meeste mainstreamdistributies aanwezig is en setuid-root draait. De page-cache-corruptie overleeft geen reboot of cache eviction, maar daar heb je weinig aan als de aanvaller eerst een root shell krijgt en daarna eigen persistentie neerzet.
Remediatie
De echte fix is een gepatchte kernel, niet een update die alleen maar geinstalleerd staat. Voer de kernelupdate van de vendor door en reboot er effectief in. Op grotere omgevingen rol je dat bewust uit: cordon en drain Kubernetes-workers, recycle CI-runners, en herstart bastions of gedeelde shellhosts. Een host die de fix al heeft gedownload maar nog op de oude kernel draait, blijft kwetsbaar.
Als een gefixte kernel nog niet beschikbaar is, schakel dan het kwetsbare pad uit. Op systemen waar algif_aead laadbaar is, blokkeer je die module persistent via een modprobe-regel en unload je ze als ze al geladen is. Ubuntu's tijdelijke mitigatie doet exact dat via een bijgewerkt kmod-pakket, en SUSE raadt dezelfde handmatige workaround aan.
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead 2>/dev/null || true
grep -qE '^algif_aead ' /proc/modules && echo "algif_aead still loaded" || echo "algif_aead not loaded"Behandel AF_ALG als attack-surface-control in omgevingen met een gedeelde kernel. Als je containers, notebooks of CI-jobs draait voor minder vertrouwde gebruikers, blokkeer dan AF_ALG-socketcreatie via seccomp of een gelijkwaardige policy. Dat is geen theorie. Het haalt de allereerste verplichte stap uit het exploitpad weg.
Controleer de werkelijke runtime-status, niet het change-ticket. Controleer uname -r na de reboot, bevestig dat algif_aead uit /proc/modules verdwenen is als je voor de tijdelijke workaround koos, en wees eerlijk over de plekken waar lokale code-uitvoering per ontwerp normaal is. Daar verdient Copy Fail urgente aandacht.
Als je hulp wilt bij het in kaart brengen van gedeelde-kernelblootstelling in je omgeving, of bij het valideren of je Linux-hardening deze klasse van privilege escalation blokkeert, neem contact op.
