Home   2026-10-22 19:56:51

←

Ubuntu-gebruikers krijgen voortaan elke week kernelupdate

Original article

Canonical gaat sneller kernelupdates uitbrengen voor Ubuntu, zijn Linux-distributie. Het bedrijf brengt daardoor effectief iedere week een nieuwe kernelupdate uit. Het bedrijf doet dat vanwege het grote aantal kwetsbaarheden dat wordt aangetroffen met behulp van AI.

Tot op heden had Ubuntu twee verschillende updatecycli. Iedere vier weken kreeg het OS een volledige kernelupdate, met eventueel beveiligingsupdates iedere twee weken. Voortaan hanteert Canonical voor alle updates een cyclus van twee weken, zegt Canonical nu in een blogpost.

Dat betekent effectief dat gebruikers iedere week een nieuwe kernelupdate kunnen verwachten. Canonical werkt namelijk tegelijkertijd aan meerdere updatecycli. Het diagram hieronder legt dat uit.

Canonical Ubuntu-cyclus kernelupdates
Canonical test iedere kernelrelease twee weken lang, maar brengt daardoor effectief iedere week een nieuwe versie uit. Beeld: Canonical

Om dat voor elkaar te krijgen, hanteert Canonical dus ook een testcyclus van twee weken. De eerste week wordt de kernel klaargemaakt voor het OS, waarbij wordt bekeken welke updates precies worden doorgevoerd. De tweede week wordt de kernel in de praktijk getest en gecertificeerd.

Gebruikers kunnen er eventueel voor kiezen om beveiligingsupdates extra snel te ontvangen. Dat kan via een 'proposed'-pocket. Kernelupdates worden daar gepubliceerd door Canonical voordat ze zijn getest en gecertificeerd. Gebruikers moeten dat handmatig inschakelen, al wordt dat niet aangeraden vanwege het gebrek aan testtijd.

Canonical voert de wijzigingen door vanwege AI. Er worden enorme hoeveelheden kwetsbaarheden in allerlei software gevonden door AI-modellen. Dat geldt ook voor de Linux-kernel. Daardoor groeit de backlog van patches ook steeds harder, zegt Canonical. Daarom moeten de updates sneller worden uitgerold.

Kwestbaarheden in de Linux-kernel. Bron: Canonical
Het aantal bekende kwetsbaarheden in de Linux-kernel groeit explosief, vooral vanwege AI. Bron: Canonical

Door Daan van Monsjou

Nieuwsredacteur

Feedback • 24-09-2026 12:58 70

24-09-2026 • 12:58

70

Lees meer

Reacties (70)

Qua servers ben ik zelf groot fan van AlmaLinux (RHEL compatible). Die patchen zelf actief kwetsbaarheden en releasen die direct. Samen met DNF Automatic kun je de server zelfstandig laten rebooten wanneer een van de updates een reboot nodig heeft.

[Reactie gewijzigd door Saeverix op 24 september 2026 13:30]

Ubuntu kent dit ook via unattended upgrades: https://help.ubuntu.com/community/AutomaticSecurityUpdates Hiermee kan je ook aangeven dat je alles wilt updaten en herstarten indien benodigd. Op enkele van mijn thuis servers heb ik dit ook aan staan en tot op heden nog nooit problemen mee ervaren na drie jaar.
Ik laat de restart zelf niet afhangen van de optie in unattended upgrades zelf, maar maak een systemd service die restart op een vast tijdstip, maar enkel wanneer de reboot flag actief is, dit geeft me meer controle over het moment wanneer de service herstart wordt.

In ubuntu wordt deze flag automatisch aangemaakt, maar ik gebruik Debian en die doet het niet by default, daarvoor moet je need restart installeren:
sudo apt install needrestart

als je wil dat needrestart ook automatisch services herstart die het nodig hebben na een reboot:
sudo sed -i "s|^#\?\$nrconf{restart}\s*=.*|\$nrconf{restart} = 'a';|" /etc/needrestart/needrestart.conf
Je kan in unattended upgrades aangeven hoe laat je wilt restarten als het nodig is, wat voegt needrestart precies toe?

`Unattended-Upgrade::Automatic-Reboot-Time "05:46";` herstart om 5:46 precies - indien nodig.
Met een systemD service kan je niet enkel het uur, maar ook de dag instellen, bijvoorbeeld op zondag nacht
ah, check :) kan mij voorstellen dat dat handig is :) thanks!
Was onvermijdelijk. En ben blij dat Canonical dit doet. Hoe irritant opnieuw opstarten ook is
Canonical biedt ook LivePatch aan. En Solaris had lang geleden al een manier om kernel te herstarten zonder de applicaties noodzakelijk te herstarten. Het is relatief goed mogelijk om gelijkaardige functionaliteit te bouwen.

[Reactie gewijzigd door Guru Evi op 24 september 2026 13:09]

Live patchen is volgens mij niet mogelijk voor elke kernel bug. Ook wordt het niet aangeraden om lange tijd op een kernel te draaien die een live patch heeft gekregen. Daarnaast weet ik niet hoe het systeem omgaat als je meerde live patches over elkaar heen draait.

Live patch is beschikbaar bij Ubuntu Pro. Je krijgt 5 gratis seats voor thuisgebruik,
Hoe werkt dat: niet aangeraden langdurig op een live patch te draaien zonder herstart? Waarom zou dat wenselijk zijn? Mijn simpele logica zou zeggen: of het is gelukt de update uit te voeren en de relevante instructies en code wijziging zijn doorgevoerd, of niet. Maar dit impliceert een soort incomplete update? Ik kan er bij dat sommige updates niet goed gaan, maar dan staat er gewoon alsnog het verzoek om te herstarten. Ik ben wel echt nieuwsgierig waarom je alsnog zou herstarten, terwijl de update gewoon gelukt is uit veiligheidsredenen
Dit is hoe ik het begrijp, maar het zou leuk zijn als er misschien iemand is die echt sterke achtergrond in deze materie heeft.

Als eerste wordt met live-patch niet alle patches uitgerold, enkele hele specifieke en kritische patches worden uitgevoerd. Daarnaast kunnen niet alle patches op deze manier worden toegepast. Er is dus kans dat een bepaalde high vulnerability patch niet kan worden toegepast met live-patch. De live-patches worden in memory uitgevoerd. Pas bij een reboot kun je daadwerkelijk de nieuwe kernel gaan gebruiken.
Het grootste probleem is inderdaad dat niet alles kan gepatched worden dus mensen denken dat ze veilig kunnen draaien voor maanden of zelfs jaren terwijl bepaalde dingen niet gepatched zijn.

Daarnaast kunnen objecten en modules die in gebruik zijn (vb netwerkdrivers) niet patchen zonder de onderliggende hardware/software te herstarten, dat is allemaal mogelijk maar niet noodzakelijk zonder onderbrekingen, dus als een functie langdurig in gebruik is, kan de code wel gepatched zijn maar de functie in het programma van het geheugen heeft misschien gestart en data geaccepteerd met de oude conditie zodat later nog steeds een buffer overflow kan veroorzaken.

[Reactie gewijzigd door Guru Evi op 24 september 2026 16:42]

Een live patch is een plijster. Het past de kernel in het geheugen aan.

Dit soort patches kan extra problemen veroorzaken of gewoon gehele functionaliteit uitschakelen. Verder is de code van de live patches natuurlijk snel bij elkaar gegooit. Het doel is immers om zo snel mogelijk veilig te zijn terwijl je je klaar maakt voor een reboot en de nieuwe kernel.

[Reactie gewijzigd door kuurtjes op 24 september 2026 16:32]

Goh dan gebruik ik eens een Nederlands woord in plaats van gewoon ne plakker zoals wij in Vlaanderen zeggen :+
Ah, maar die had ik ook begrepen hoor. Mijn reactie was ook off-topic. Mijn excuses, fijne zuiderbuur.
Even zonder enige vorm van kennis over het livepatch proces; Maar ik kan me voorstellen dat kernel instructies die je CPU of memory instructies raken ingewikkeler zijn om live te swappen dan bijvoorbeeld de kernel instructies die je geluidskaart aansturen.
Ben redelijk nieuw op Linux, dus wacht rustig mijn updates af :)

Maar bedankt!

[Reactie gewijzigd door b4rtw op 24 september 2026 13:09]

Bij suse heet dat live patching https://www.suse.com/products/live-patching/

Ik vindt het knap hoe ze het doen.
Moderne computers herstarten in een kwestie van een minuut, is dat nou echt zo erg?
Het opstarten zelf niet, maar het ligt er ook aan hoe het OS omgaat met applicaties die al open staan. Weet eigenlijk niet hoe dat bij Linux tegenwoordig is, maar bij Windows vind ik het wel fijn dat applicaties weer automatisch geopend worden. Zeker op mijn werklaptop is het fijn dat ik meteen weer verder kan waar ik gebleven was.
verschilt per distro en hoe je deze hebt ingericht. Mijn cachyos opent alles weer opnieuw zoals bij afsluiten, maar dat doen ze niet allemaal.
Kubuntu ook, dus ubuntu waarschijnlijk ook.

Vind het persoonlijk mega irritant en zet het altijd direct uit. Ben een sloddervos met tientallen open vensters. Afsluiten zorgt ervoor dat ik s morgens tenminste met een schone lei begin.
Is dit ook voor xubuntu
Kan je dat niet instellen dan? Ik kan dat met Debian 13 Xfce wel. Kan ook met KDE overigens.
De meeste applicaties kunnen niet overweg met vervanging van (systeem) shared libraries. Je kunt niet even memory mapped spul omleggen naar een andere shared library.

Wat wel kan is dat een programma een 'state' kent (of soort transactielog), waarmee een programma 'terug kan naar waar het was'. Voor bijv. een tekstverwerker is dat makkelijker dan voor een programma met dynamische content.
Mijn Linux machine wou daarstraks niet uitgaan omdat er nog een Windows VM in QEMU aan het draaien was. Natuurlijk moest ik eerst nog Windows updates doen voordat ik men huis uit kon, zelfs al draai ik Linux.
Hangt er van af waar je mee bezig bent en hoe goed al je applicaties zijn in het herstellen van de staat waarin ze stonden. Bijkomend gaat je omgeving zichzelf niet zomaar terugzetten in de achtergrond, daar moet je als gebruiker weer eerst voor aanmelden, dus als je aanmeldt en dan nog enkele minuten nodig hebt voordat alles weer op zijn plaats staat verlies je daar ook weer tijd mee die je niet nuttig kunt besteden.

Een OS start vandaag in seconden op, de usersessie is wat tijd kost.
Het opnieuw opstarten is niet zozeer het probleem, de tijd die het stil ligt, kan best een heel bedrijf stil leggen. Dan lopen de kosten hoog op, zeker als het opstarten van dergelijke grote omgevingen even duurt.

[Reactie gewijzigd door CH4OS op 24 september 2026 14:36]

Het opnieuw opstarten is niet zozeer het probleem, de tijd die het stil ligt, kan best een heel bedrijf stil leggen. Dan lopen de kosten hoog op, zeker als het opstarten van dergelijke grote omgevingen even duurt.
Je draait in zo'n geval toch wel met meerdere machines die je dan omstebeurt reboot?
Ligt er maar net aan, als het een proces is met een peperdure machine, kan ik me voorstellen dat je niet "high availability" hebt voor dergelijke machines. Zo weet ik bijvoorbeeld dat bij een supermarkt keten de winkels niet bevoorraad kunnen worden, wanneer een bepaalde applicatie niet draait. Die applicatie is alleen niet met high availability uitgevoerd. Dat was destijds ook totaal geen ding, het moest gewoon werken. Echter gebruikt men de applicatie nog steeds, want... Het werkt toch?

[Reactie gewijzigd door CH4OS op 24 september 2026 18:24]

als het echt veel kost o
Ligt er maar net aan, als het een proces is met een peperdure machine, kan ik me voorstellen dat je niet "high availability" hebt voor dergelijke machines. Zo weet ik bijvoorbeeld dat bij een supermarkt keten de winkels niet bevoorraad kunnen worden, wanneer een bepaalde applicatie niet draait. Die applicatie is alleen niet met high availability uitgevoerd. Dat was destijds ook totaal geen ding, het moest gewoon werken. Echter gebruikt men de applicatie nog steeds, want... Het werkt toch?
Als het echt veel kost om down te gaan doe je iets niet goed als je niet redundant draait. Een server die heel duur is in vergelijking met downtime in een hele grote productieomgeving, nou dat lijkt me een niche. Ja, er zal vast wel een situatie zijn die rond het omslagpunt zit. En ik vind je voorbeeld waarbij ontwerpkosten (zo lees ik het) een rol spelen ook wel interessant.

Maar in je voorbeeld met de supermarktketen, is het daar een probleem dat de server vijf minuten offline is? En is er over nagedacht dat het systeem niet het eeuwige leven heeft?

Vergeet ook niet dat iets dat een groot bedrag voor de gemiddelde mens een schijntje is. Een keer in de vijf jaar een jaarsalaris uitgeven aan twee servers en wat software stelt niks voor als er duizenden mensen werken.
Voor je desktop misschien niet, maar Ubuntu wordt ook gebruikt voor servers.
Het OS zelf wel. Maar een BIOS van Dell of HP servers.... Daar kun je wel een paar minuten voor uittrekken.
Een herstart van een server kan zomaar 10 minuten duren, door alle hardware checks. Het OS zelf start inderdaad binnen een minuut.
Moderne computers herstarten in een kwestie van een minuut, is dat nou echt zo erg?
Toen Microsoft besloot elke maand op een vooraf bepaalde dag updates te gaan releasen voor Windows was de wereld te klein. Maar nu is het niet erg.
Ik vond het toen ook al geen probleem.
Ach er is zoveel verandert....

Vroeger als een stukje software alleen voor windows uitkwam dan was de wereld te klein. Er waren immers ook andere besturingssystemen.

Als er nu linux only features gebruikt worden en het alleen voor linux is en andere OS'en eigenlijk een beetje buiten de boot vallen dan roept men dat je maar in moet stappen op de linux trein. Daar gebeurt het, de rest doet er niet meer toe.
Op een personal computer nee, op een server is dat wat lastiger, alhoewel je een server die hoge uptime nodig hebt wel best in HA zet.
Heb je wel eens een server zien (re)booten? Dat kan echt wel lang duren. Het OS zelf is in een paar seconden wel gestart, dat klopt. Maar daar gaat vaak heel wat aan vooraf.
Moderne computers herstarten in een kwestie van een minuut, is dat nou echt zo erg?
In een keten kan dat inderdaad een probleem zijn. En een omgeving met honderden of meer gebruikers die 50-100 euro per uur kosten is dit minder wenselijk.

Thuis heb ik iets van 20 Linux servers (containers) draaien. Die worden allemaal geüpdatet met Ansible. En die worden in de nacht herstart indien nodig.
M.i. is rebooten een must na een kernel update of driver/OS software. Zelfs na configuratiewijzigingen is het verstandig.

Als je het niet doet en bv 2 weken later gaat er iets mis dan is het verband met die wijziging niet snel meer gelegd.
Ik reboot atijd na een kernel update en microcodes. Voor de rest gebruik in needrestart of er een herstart nodig is.
Dat is een keuze, ik heb b.v. wel eens wat aan de fstab of automounter gedaan wat niet helemaal klopte. Weken later pas een reboot gedaan en tja, waarom doet ie ut nou nie?

Sinds die tijd heb ik die boottijd er graag voor over, en ja ook op enterprise spul wat doorgaans een eeuw nodig heeft om door de POST te komen.
Het is in principe niet nodig mits applicaties hun dependencies een beetje goed hebben aangegeven en je de nodige services herstart na een update. Ik check altijd htop om te kijken welke binaries er allemaal een periodieke herstart nodig hebben.

De enige updates waar ik tegen dingen aanloop als ik niet herstart zijn de updates voor de Nvidia-drivers, maar daar verwacht ik er niet zoveel van nu Nvidia geen nieuwe versies meer maakt voor mijn GPU.
Hoe erg is dat? Eind van de week ipv lock een reboot? Je zou het zelfs automatisch kunnen doen. Vrijdag om 23:55 herstarten.

Of heb jij dingen op je PC draaien die je 24/7 beschikbaar wilt hebben?
Op je desktop wellicht niet, maar servers wel. Het gros van de servers draait Linux. Die van ons rebooten eigenlijk nooit. Zeker niet voor een kernel. Noem 1 kernel exploit die remote valt te misbruiken.
Noem 1 kernel exploit die remote valt te misbruiken.
CVE-2024-26592
Op je desktop wellicht niet, maar servers wel. Het gros van de servers draait Linux. Die van ons rebooten eigenlijk nooit. Zeker niet voor een kernel. Noem 1 kernel exploit die remote valt te misbruiken.
Ik zou liever geen gevoelige data bij jullie zetten... .Dit klinkt toch een beetje als een mentaliteit die in 2001 al twijfelachtig was.
Verbazingwekkend hoeveel moeite sommigen hebben met de herstart van een heel system.

Als het om msWindows systemen gaat, dan kan ik mij voorstellen dat je moeite hebt met een herstart tijdens het patchen, omdat msWindows draaiende binaries niet kan vervangen moet ze bij de shutdown en het opstarten veel van de patch-taken uitvoeren. Het komt zelfs voor dat systemen 2 of 3 keer moeten herstarten in de patch/update-reboot.

Maar unix en linux gebaseerde systemen kunnen draaiend heel goed alle files op het draaiende systeem vervangen. Daarmee is een groot deel van het patch proces in het draaiende systeem uit te voeren. En daarmee is de herstart van het systeem rond patchen geheel vergelijkbaar met een normale herstart.

Toegegeven: er zijn linux systemen die patch/update acties wel in de herstart zetten. Dat is een keuze van de gebruikte patch-tool en/of de distributie.
Toegegeven: er zijn linux systemen die patch/update acties wel in de herstart zetten. Dat is een keuze van de gebruikte patch-tool en/of de distributie.
Linux systemen worden steeds complexer en systemd services kunnen onderling complexe afhankelijkheden hebben waardoor het veiliger is om alles bij herstart een offline update uit te voeren.

Ik weet in ieder geval dat Ubuntu dit doet voor bepaalde updates.
I'm ben benieuwd wanneer de golf van Kernel-Buga "klaar" is. Ergens ben ik best blij dat er nu eventjes een miljoen patches zijn, en daarna de software relatief veilig is.
Het begint nu net. Het wordt de komende jaren alleen maar erger naarmate AI beter wordt in het vinden van kwetsbaarheden.
Oneindigheid voorspellen in een eindige hoeveelheid code lijkt me onwaarschijnlijk. Dat er in de kernel veel bugs zaten staat buiten kijf, maar je moet vroeg of laat nieuwe typen aanvallen bedenken als je tot het oneindige zou willen doorgaan met bugs vinden, en ik twijfel of dat kan. Voor deelsystemen zoals bij cryptografie zal zoiets in de komende decennia vast enkele keren gebeuren, maar een fundamenteel nieuw type bug (waar alle software kwetsbaar voor is omdat niemand eraan gedacht had) wordt niet aan de lopende band gevonden. Tot dusver zijn LLM's er ook nog geen tegengekomen
Debian draait op Linux 6.12.107 LTS release. Debian volgt daarbij de releases van de LTS kernel zelf. De .107 kernel is van einde augustus. Inmiddels is de 6.12.111 LTS al uitgebracht.

Ben benieuwd of Debian ook druk voelt van de toegenomen kernel bugs en of zij ook een plan hebben om hierop te anticiperen. Met Debian voel ik meer binding omdat het een community project is, maar met dit soort zaken laat het zien dat een commerciële organisatie ook voordelen bied als je bepaalde garanties wil hebben op het gebied van updates.
De laatste tijd met de Dirty Frag exploits enzo, waren de fixes op mijn Debian systemen weken/maanden sneller beschikbaar. Omdat ze de officiële Linux LTS gebruiken, kunnen ze gewoon upstream pakken. Voor Ubuntu is dat veel moeilijker, helaas.
-

[Reactie gewijzigd door Bedge85 op 24 september 2026 16:00]

het zou ze sieren af te stappen van dat hele ubuntu pro verhaal. nu moet je een pro abonnementje afsluiten wil ook alle andere updates krijgen. nu krijg je slechten de criticals.
Even de reacties gescand (kan natuurlijk iets missen), maar zo op het eerste oog zie ik nergens het risico aangehaald dat AI bewust beveiligingsproblemen meldt en daar een zelfontwikkeld lek aan toevoegt dat wij niet zomaar één, twee, drie zullen vinden.
Goed dat ze dit nu voor Debian doen. Maar moet dit niet eigenlijk voor meer systemen gedaan worden?
Denk aan alle NAS systemen dat mensen hebben thuis. Of firewall software?
Er staat Ubuntu in het artikel. Geen Debian. Dus is nog afwachten wat de debian distro gaat doen.
De meeste nassen hebben een kernel uit een ver verleden helaas. Zou mooi zijn, maar denk niet dat we dat snel gaan zien.
Met een NAS mag je al blij zijn als ze af en toe je userland patchen. Meestal letten die niet zo op security en al helemaal niet op de kernel. Ik ken iemand met een Synology die nooit een update naar versie 7 heeft gehad |:(
1 t/m 6 is toch ook een net aantal jaren geweest? Ergens houdt het een keer op als je bij aanschaf een vaste prijs betaald hebt en geen onderhoudscontract afsluit
Nee hoor. Dat is alleen zo bij commerciële troep. Ik draai al sinds de jaren '90 Linux en daar heb ik nog nooit voor betaald of een onderhoudscontract voor gehad. Ik kan een 20 jaar oude PC nog van een moderne distro voorzien als ik wil. Wellicht is het te langzaam en niet prettig in gebruik, maar het kan dus wel gewoon.
Wat voor kernels gaat dit over dan? Want zo vaak komen er niet nieuwe kernels uit toch?
We hebben het hier over ubuntu, ubuntu sleutelt zelf heel erg aan de kernels.

Zo word ubuntu door commvault bijvoorbeeld niet ondersteunt als het gaat om block level backups. Puur door alle patches aan de kernel die ubuntu doet.
En VMware loopt al zover achter met zijn kernel support : )
Laten ze net als Fedora ook 1 of 2 oude kernels geinstalleerd staan als fallback?
Heb wel eens issues gehad na een kernel upgrade en dan is het toch fijn dat ik makkelijk terug kan naar een oude.

Om te kunnen reageren moet je ingelogd zijn