ik heb al kernel 7.0.0-38 in Mint :-)

Haha, in de derde regel staat al
"die kunnen leiden"

Dat is hetzelfde als de straat oversteken, en niet uitkijken :-)

Dit moet een nieuw record zijn.

Goed bezig. Timmer het maar dicht.
En zo spectaculair is het aantal blijkbaar niet...

tja die 6.12 is een LTS dus dit zijn heel veel 'back-ports' in een keer tegelijk waarschijnlijk nu Debian hun 6.12.107 eens updaten. Het is dus niet zo dat de laatste mainline [7.2.8] ineens deze week nu zo veel patches heeft.

"Elke commit waarmee een potentieel beveiligingsprobleem wordt opgelost krijgt nu een CVE-nummer toegekend, ook als het om een klein probleem gaat of er geen bekende exploitmethode is."

Dit is echt een heel slecht idee. De hele gedachte van een CVE schop je daarmee onderuit. Een CVE wordt daardoor nikszeggend.

Alle nieuwsorganisaties/developers moeten dus naast zeggen dat een issue ‘een CVE’ betreft ook de ‘severity’ vermelden, het woord CVE op zich zegt nu helemaal niets meer. Mogelijk alleen CVEs rapporteren met een score 7 of hoger (ie. High/Critical) en de rest in een bijlage stoppen in het gebal van change/release notes.

Dit is het gevolg van de AI-analyse van de Linux kernel codebase. Met als gevolg dat deze nog harder te kraken wordt.

Integendeel. Bugs in de kernel zitten op een plek waar, als misbruik mogelijk is, de consequenties meteen heel ernstig kunnen zijn, want de kernel is de code die echt alles mag op een systeem. Een probleem dat klein lijkt of waar geen exploitmethode voor bekend is kan opeens een levensgroot probleem blijken te zijn als een aanvaller heeft ontdekt hoe het te misbruiken is, vaak in combinatie met een of meer andere bugs die er ook onschuldig uitzien. En de praktijk wijst al decennia lang uit dat je lang niet altijd aan een bug kan zien hoe goed die te misbruiken zal blijken te zijn. Je weet dus helemaal niet hoe ernstig je hem moet nemen. Dus hoe voorkom je ellende met dat soort bugs? Door ze allemaal bloedserieus te nemen en ze altijd direct te repareren, voordat een kwaadwillige ontdekt hoe die de bug kan misbruiken. En hoe krijg je al die lieden in beweging die, net als jij, denken dat ze het pas ernstig hoeven te nemen als er al misbruik bekend is? Juist, door meteen al een CVE uit te schrijven.

Je wordt middels die CVE's met je neus op het feit gedrukt dat je bugs in de kernel bloedserieus moet nemen, zelfs als nog niet bekend is hoe ze misbruikt kunnen worden. De juiste reactie daarop is niet om te stoppen CVE's ernstig te nemen, maar juist om die bugs serieus te gaan nemen. De mensen die de ontwikkeling van de kernel leiden zijn niet op hun achterhoofd gevallen, die zijn juist toppers in dit soort dingen. Die maken dit soort keuzes niet voor niets. Ontken het signaal dus niet dat ze je geven, neem het juist bloedserieus.

OpenBSD hanteert trouwens al decennia de aanpak om een permanent auditteam naar bugs te laten zoeken, niet specifiek beveiligingslekken, en elke bug direct te repareren. Die zijn daarmee beveiligingslekken die de andere BSD's hebben domweg meestal voor, een of meer van de bugs die samen te misbruiken zijn zijn al al gerepareerd voordat wie dan ook ontdekt heeft hoe dat misbruik kan. Ze hebben zo de reputatie opgebouwd een zeer veilig systeem te maken. De aanpak is niet identiek, maar de Linux-kernelontwikkelaars doen iets vergelijkbaars, en dat komt in die CVE's tot uiting.

Effe kijken. In Debian zijn de nodige nieuwere kernel-versies via de repository stable-backports beschikbaar, met 7.1.13 als recentste. Het is alleen niet de default-versie, Debian kiest altijd voor stabiliteit in de features binnen een major release van stable, en als je the latest and greatest wilt dan daar in zit kijk je of als "backport" beschikbaar is, of dat de leverancier zelf rechtstreeks een debian-repository aanbiedt. Ik haal bijvoorbeeld Firefox op die manier rechtstreeks bij Mozilla vandaan.

Mij staat trouwens bij dat in Mint ook niet de recentst beschikbare kernel-versie de default is, de laatste keer dat ik daar iets van zag werd er dacht ik ook een 6.x-kernel default geïnstalleerd terwijl er al 7.x-kernels beschikbaar waren. Klopt dat?

Je hebt de laatse heel veel jaar het CVE concept niet ontmoet , en dat dat elke CVE even erg was, en allemaal betekende "het hele Internet kan je hacken" als er een CVE is ?

Zo werkt het al _tijden_ (altijd ? 20+ jaar sinds "nieuwe CVE systeem" ? ) . Er hangt ook een severity score aan de CVE (CVSS), afhankelijk van moeite van exploit risico (bv - local user nodig, authenticated user, remote access etc etc_
https://www.cve.org/about/relatedefforts

Ook vergezochte "risico's" kregen wel een CVE - nogal eens om het CV van de researcher op te poetsen.
AI heeft zowel het vinden van kleine bugs, als het creeren van complexe exploits makkelijker gemaakt.

http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/

(heel erg lezenswaardig)

Nee net als bij microslop zijn er veel fouten in het verleden niet echt aangepakt of gebackport naar oudere kernels omdat het exploiteren ervan te lastig was. Wat met AI goed kan is er op los halicuneren zodat onwaarschijnlijke combinaties van fouten in beeld komen, in combinatie met snelheid en schaal maken kleine onbenullige bijzaken in eens een opstapje voor een andere.

Goed zo. Vragen om problemen.

(Kernel 6.8 serie is voor de huidige Mint 22.x)

Vanuit mijn laatste beroep - heel iets anders dan in de IT - weet ik hoe 'annoying' veiligheid (security) kan zijn maar ik ben bang dat de huidige stortvloed aan veiligheidsupdates weleens averechts zou kunnen gaan werken. Gebruikers zouden wel eens updatemoe kunnen worden.

Het laatste half uur begon ik er in mijn Linux Mint Cinnamon ook wel enigszins van te balen. De update van de Kernel van 6.8.0-142 naar 6.8.0-146 was afgerond, daarna herstart (moet in Mint 22.3) en... alweer dient zich een update aan, ditmaal van LibreWolf (Firefox fork).

Het is natuurlijk niet verstandig te denken: uitstellen, maar de verleiding wordt groot updates automatisch te laten installeren als ze met zo'n kleine interval blijven binnenrollen, maar dat is ook niet raadzaam.

Bijvoorbeeld een jaar of zo terug werd mij (toen nog in Mint 22.1) foutief de bestandsbeheerder Nautilus aangeboden in Bijwerkbeheer (Nemo is bestandsbeheerder in Mint).
Je moet er niet aan denken twee kapiteins op een schip te hebben doordat je zo'n update zonder controle geautomatiseerd installeert.

Voor Debian?
Nuh, 82 procent van alle software versies in hun distro is zo oud dat het vast wel ergens vermeld staat in
een lijst met lekken. :P

Je kan ook gewoon de automatische updates aanzetten met unattended-upgrades.

Andere anoniem: Als u in de uodater kijkt onder kernel management kunt u kiezen uit kernel 7 versies.
Dit is bedoeld voor nieuwere systemen die niet werken op kernel 6 versies.
Daarnaast worden de beveiligingspatches gebackport naar andere kernel versies.
Ik zit zelf ook op 7.0.0-38, dit is gewoon beschikbaar gesteld door Debian, kernel 7 is gewoon veilig.

Debian is geen Mint.
Anoniem heeft gelijk.

Momenteel, 03-10-2026:

Ja. Klopt nog steeds.
Zie eerste alinea hier: https://www.linuxmint.com/rel_zena.php

P.s. Niet kwetsend bedoeld hoor, maar al langer vraag ik mij af:
Lezen Linux gebruikers nog wel eens de first line documentation m.b.t. de door hen gebruikte distro's? Ik betwijfel dat als ik alle reacties ook hier weer overlees.

Paar dagen geleden was er nog een talk over CVE in de kernel bij Greg Kroah-Hartman . "Kernel Recipes 2026 - Security in the LLM age" https://youtu.be/NnV_cWeoo5Q

Die heb ik er na de update gelijk weer afgeknikkerd. Hele OS bevroor. Zelf niet te redden met ctrl-alt-backspace, ctrl-alt-F2 of grub parameter -nomodeset.
Ik ben weer terug naar kernel 6

Je antwoordde op mij. Ik gebruik zelf Debian, niet Mint. Maar het gebeurt incidenteel dat ik er toch even mee in aanraking kom. Maar van Mint ben ik dus heel wat slechter op de hoogte dan van Debian.

Debian is Debian, Red Hat is Redhat, maar de kernel staat daar los van, die is voor elke distro aardig gelijk.

FF niet zo lekker van Debian:

(Deb 11 Bullseye - EOL, maar security repo niet naar archive gemigreerd)

https://lists.debian.org/debian-mirrors/2026/09/msg00002.html

In het opensource wereldje wordt er meestal niet gewacht to een volgende patch dinsdag oid voor release van bugfixes, zo komen beschikbaar zodra het klaar is... Dus je kunt zelf kiezen voor een patch dinsdag of continue...
Je kan ook kiezen voor automatisch security updates of alles...

Secirity archive is vziw alleen voor tijdelijke fixes to een goede fix gemaakt is en regulier verspreid.
Na EOL komen er geen security fixes meer.

Tja, dit is wel een EOL-versie, een die sinds 31 augustus niet meer wordt ondersteund. Het kan zijn dat ze een steekje hebben laten vallen, het kan ook zijn dat ze hoe dan ook geen grote haast maken in het afwikkelen van iets dat niet meer ondersteund wordt, omdat wat nog wel ondersteund wordt urgenter is. Moeilijk te zeggen.

Hoe je dat ook moet beoordelen, het is niet zo dat iemand op een versie waar geen support meer wordt gegeven nog support moet verwachten. Iedereen die een vervallen versie van Debian (zoals 11-Bullseye) blijft gebruiken doet dat hoe dan ook geheel op eigen risico en zou moeten snappen dat dat geheel op eigen risico is.

En wat kan er misgaan? Het is echt niet zo dat een Bullseye-systeem onderuit gaat hierdoor. De repository's, of ze nou wel of niet naar archive gemigreerd zijn, gaan geen wijzigingen meer opleveren in geïnstalleerde software. Als er iets ontbreekt kan de update/upgrade-actie erop stuklopen, maar die brengt hoe dan ook geen veranderingen meer aan op het systeem. Het is niet zo dat er opeens software van die systemen wordt verwijderd of zo. De actie geeft een fout, de rest van het systeem hobbelt exact zo door als het anders ook had doorgehobbeld. Je kan de fout elimineren door het update-proces dat toch niets meer doet uit te zetten. Zo'n systeem kan onderuitgaan door beveiligingsproblemen die niet meer gerepareerd worden, maar niet omdat een update/upgrade niet meer lukt die hoe dan ook niets meer gedaan zou hebben.

Bij welke software dan ook geldt dat als je iets gebruikt waar geen support meer op wordt gegeven je dat op eigen risico doet.

Dan geldt bij Debian nog dat het een non-profit is die op vrijwilligers draait, en dat bij die LTS-ondersteuning, die ze warempel geven, al 5 jaar vooruit wordt aangekondigd wanneer die eindigt. Dan vind ik het eigenlijk maar de vraag of je dit niet zo lekker van Debian moet vinden. Misschien is het wel niet zo lekker om vrijwilligers te vragen aandacht te steken in iets dat geen aandacht meer zou krijgen, en waarvan al 5 jaar bekend was wanneer dat op zou houden.

Debian wijzen op de onvolledige migratie naar archive heeft zin, daarbij gaan aanvoeren dat je er zelf last van hebt omdat je iets gebruikt dat domweg niet meer ondersteund wordt, en waarvan ook al 5 jaar bekend was wanneer het niet meer ondersteund zou worden, dat vind ik een stap te ver gaan, dat is dan echt je eigen probleem.

Nee, dat zit bij Debian anders. In Debian stable worden in beginsel geen functionele wijzigingen doorgevoerd, je systeem werkt zoals je gewend bent dat het werkt tot de volgende major release. Dan kan het als volgt gaan voor een hypothetisch pakket:

• Er komt een nieuwe versie van Debian stable uit met daarin versie 3.14 van dat pakket.
• De makers ("upstream") van het pakket brengen los van Debian versies 3.15, 3.16 en 3.17 uit, met functionele wijzigingen, nieuwe toeters en bellen. Die neemt Debian niet over, dat werkt immers met qua functionaliteit bevroren versies (als je althans als gebruiker geen nieuwere versie uit de backports-repo installeert, maar dat is een uitzondering op hoe het standaard werkt).
• Dan wordt er een beveiligingslek in versie 3.17 ontdekt, en uptream brengt 3.17.1 uit met de reparatie daarvoor.
• Het security-team van Debian kijkt of die bug ook in 3.14 al zit. Dat hoeft niet per se, het kan een fout zijn in code die in een van die nieuwere versies is toegevoegd, maar laten we zeggen dat het probleem ook al in 3.14 blijkt te bestaan.
• Het security-team van Debian neemt de reparatie van upstream over en brengt die in versie 3.14 aan, en brengt die uit met een eigen toevoeging aan dat versienummer, bijvoorbeeld 3.14~deb13u1 (update 1 voor dit pakket in Debian 13 zal dat betekenen).

Dat is geen tijdelijke fix, dat is een backport van de definitieve fix naar de versie die Debian voert. Soms is Debian overigens zelf degene die de fout herstelt en de fix aanlevert bij de makers van het pakket, maar daar zijn ze de enige niet in.

Een gevolg van deze werkwijze is dat je bij Debian niet zomaar simpelweg naar de versienummers kan kijken om te zien of een fix al is aangebracht. Als je in de media ziet dat je 3.17.1 nodig hebt betekent 3.14~deb13u1 niet dat het het er niet in zit, ook al ziet 3.14 eruit alsof het van voor 3.17.1 is. Vrijwel altijd heb ik een fix al geïnstalleerd op mijn (privé-)systeem als ik erover lees in de media, al zijn de versienummers anders.

Dat klopt.

Door het fout archiveren kun je de fixes die gemaakt zijn voor 31-8-2026 (maar je nog niet had opgehaald) niet vanzelf vinden .

gewoon een nette _complete_ EOL waarin de laatste versies geindexeerd gedownload kunnen worden is echt niet teveel gevraagd.

Ga je je nu weer provocatief opstellen! Een nieuw record van wat? Heb je het stuk wel gelezen over toekennen van cve's?
Blijkbaar wordt er hard gewerkt om Debian veilig te houden is een betere conclusie.

Bij Microsoft zou het een record zijn. Geen een er van is namelijk kritiek. Het gros heeft low-severity.
Zou MS ook eens moeten doen, elke bug aanduiden als mogelijk security probleem.
Debian doet, Microsoft niet en houdt het lekker gesloten. Daar zie je ook dat al die kritieke problemen gevonden worden door mensen buiten Microsoft terwijl ze nog niet eens inzage hebben in de code.
Transparantie is waar het tegenwoordig over gaat. Zal wel even wennen voor je zijn.