In nog geen drie weken tijd verschenen er vier kernel-lekken op rij — alle vier lokale root-escalaties of kritieke info-leaks, en alle vier mét publieke exploits binnen handbereik. Voor wie multi-tenant hosting draait is dat het soort venster waarin patchsnelheid plotseling het belangrijkste KPI van de week wordt.
De interessante vraag is niet zozeer wat er lekte, maar wie het op tijd dichtgooide. De drie grote enterprise-Linuxes reageerden namelijk opvallend verschillend.
Een korte oriëntatie
Voordat we de tijdlijn induiken, even het speelveld.
AlmaLinux is een community-gedreven rebuild van Red Hat Enterprise Linux, ontstaan nadat Red Hat in 2020 de stekker uit het oorspronkelijke CentOS trok. De distributie is binair compatibel met RHEL en wordt mede bestuurd door ALESCo, een technische stuurgroep die beslissingen neemt over zaken als emergency kernel-builds. Traditioneel volgt Alma op Red Hat — die bouwt eerst, Alma rebuilt later.
RHEL is de commerciële Linux van Red Hat (sinds 2019 onderdeel van IBM); CentOS Stream is de upstream waarop RHEL gebouwd wordt. Stream zit dus vóór RHEL in de keten, niet er na, zoals het oude CentOS dat deed. Beveiligingsupdates doorlopen eerst het interne testtraject van Red Hat en worden vervolgens als RHSA-errata uitgebracht.
Ubuntu, gebouwd door Canonical, hanteert een eigen Stable Release Update-proces (SRU). Kernel-fixes volgen meestal die cyclus, met een periode van regression-testing voordat een Ubuntu Security Notice (USN) wordt gepubliceerd. Voor acute gevallen kan Canonical eerst een mitigatie uitrollen via een kmod-update, zodat de aanvalsoppervlakte verkleind wordt voordat de echte fix klaar is.
De vier lekken
Copy Fail
Het bal werd geopend eind april met Copy Fail, een fout in het crypto-subsysteem die een onbevoorrechte gebruiker root kon laten worden. Op het moment van publicatie waren er nog geen Red Hat-patches beschikbaar. Het AlmaLinux-team besloot daarop iets ongebruikelijks: niet wachten, maar zelf bouwen.
Een paar dagen later stonden hun productie-kernels live, gebaseerd op de upstream-fix — een formulering die je zelden ziet bij een downstream rebuild. Ubuntu kwam in dezelfde periode alleen met een mitigatie: een update die de kwetsbare module neutraliseerde. Voor verschillende ondersteunde Ubuntu-kernels stond begin mei nog letterlijk “no fix is available yet”.
Dirty Frag
Het tweede incident, Dirty Frag, brak begin mei los nadat het embargo voortijdig werd doorbroken. Twee gerelateerde lekken in de netwerk-stack; in combinatie genoeg om lokaal root te krijgen. Doordat exploits al publiek waren voordat de lekken officieel waren toegewezen, was de druk hoog.
Red Hat reageerde dit keer relatief snel met errata binnen een dag. AlmaLinux trok diezelfde dag eigen errata uit en had productie-kernels binnen 24 uur beschikbaar. Livepatch-leveranciers slaagden er zelfs in om binnen een dag uit te leveren — vóór de officiële vendor-errata. Ubuntu daarentegen wachtte met de definitieve kernel-fix tot begin juni — bijna vier weken na disclosure, en pas dan gebundeld met de Fragnesia-fix.
Fragnesia
Nauwelijks een week later kwam Fragnesia aan het licht — uit dezelfde codebase als Dirty Frag, en met hetzelfde root-potentieel. ALESCo besloot opnieuw expliciet om vóór Red Hat te shippen, omdat de RHEL-patches er nog niet lagen. Binnen een paar dagen stonden de productie-kernels klaar.
Red Hat bundelde Fragnesia uiteindelijk met Dirty Frag en het laatste lek in één gecombineerde errata, gepubliceerd halverwege mei. Ubuntu nam Fragnesia mee in dezelfde juni-update als Dirty Frag.
ssh-keysign-pwn
Eén dag na Fragnesia openbaarde Qualys het meest kleurrijke lek van het rijtje: een race condition waardoor een onbevoorrechte gebruiker SSH-hostkeys en /etc/shadow kon uitlezen. De bijnaam ontstond doordat de exploit chain langs setuid-binaries als ssh-keysign liep.
Voor AlmaLinux-gebruikers was dit het simpelste scenario: dezelfde kernel-builds bevatten zowel de Fragnesia- als deze fix. Eén dnf upgrade dekte beide. Red Hat verwerkte de fix in dezelfde security updates van half- tot eind-mei. Canonical publiceerde een advisory en leverde de kernel-fix in de reguliere SRU-cyclus.
Vergelijking patchsnelheid
| Lek | AlmaLinux | RHEL / CentOS Stream | Ubuntu |
|---|---|---|---|
| Copy Fail | Eigen build op upstream-fix binnen enkele dagen | Later via errata; Red Hat-patches waren bij Alma’s release nog niet klaar | Eerst alleen een mitigatie; voor diverse kernels nog “no fix is available yet” |
| Dirty Frag | Eigen errata, productie binnen een dag | Errata binnen een dag; livepatches vóór de vendor-errata | Pas begin juni, bijna vier weken na disclosure |
| Fragnesia | Productie binnen enkele dagen; bewust vóór RHEL/Stream geshipt | Pas in gecombineerde errata halverwege mei | Samen met Dirty Frag in dezelfde juni-update |
| ssh-keysign-pwn | Inbegrepen in dezelfde builds — één dnf upgrade dekte beide | Idem in de gebundelde errata van half/eind mei | Advisory door Canonical; kernel-fix via reguliere SRU |
De rode draad
Wat opvalt is dat AlmaLinux bij alle vier de incidenten de snelste enterprise-distro was, consistent binnen 1 tot 3 dagen in productie. Dat is op zichzelf bemerkenswaardig, want Alma is normaal downstream — het wacht op Red Hat en rebuild daarna. Hier werd de volgorde omgedraaid: het core-team bouwde zelf kernels op de upstream-commits, een beslissing die formeel door ALESCo werd genomen, en community-testing hielp om die builds sneller productie-rijp te krijgen dan een klein team alleen had gekund.
Red Hat en CentOS Stream liepen telkens dagen tot ruim een week achter. Bij Dirty Frag was Red Hat nog relatief vlot, mede gedreven door het feit dat het embargo gebroken was en exploits al circuleerden voordat de lekken überhaupt waren toegewezen. Maar Fragnesia en de race-condition werden pas in de tweede helft van mei in een gecombineerde errata afgehandeld. Voor CentOS Stream geldt bovendien dat fixes via het normale Stream-proces binnenkomen; er is geen apart “emergency”-spoor.
Ubuntu koos een herkenbare tweetraps-aanpak: snel een mitigatie waar mogelijk, maar de échte kernel-fixes volgden via de reguliere SRU. Dat leverde bij Dirty Frag en Fragnesia een update op die pas bijna een maand na disclosure verscheen. Wie in die periode op Ubuntu draaide moest het hebben van de mitigatie of van een livepatch.
Een kanttekening
Snelheid heeft een prijs, en AlmaLinux erkent dat zelf openlijk: ze brengen kernels uit voordat Red Hats interne testronde is afgerond, en leunen voor de validatie op de community. Bij Fragnesia moesten de testing-kernels tussentijds zelfs herbouwd worden om extra upstream-patches op te nemen.
Voor multi-tenant hosting — toevallig AlmaLinux’ belangrijkste doelgroep — weegt patchsnelheid bij een publieke local-root-exploit echter vrijwel altijd zwaarder dan een extra validatieronde. En dát is, in de afgelopen drie weken, precies wat het verschil maakte.