Qui vigili les alertes de seguretat d’un servidor Linux ho haurà notat: cada setmana apareixen desenes de CVE nous del kernel, molts amb descripcions que semblen simples correccions d’errors. No és una impressió. Des que el projecte es va convertir en CVE Numbering Authority (CNA) el febrer de 2024, l’equip que assigna els identificadors aplica una política deliberadament àmplia, i les xifres s’han disparat.
Per què el kernel es va fer CNA
Una CNA és una organització autoritzada pel programa CVE per assignar identificadors a les vulnerabilitats del seu àmbit. Abans de 2024, qualsevol CNA externa (una empresa, un investigador a través de MITRE) podia registrar un CVE contra el kernel sense passar pels seus desenvolupadors. La documentació oficial del procés, Documentation/process/cve.rst, ho explica sense embuts: els CVE del kernel «s’assignaven molt sovint de manera inadequada i per raons inadequades», i els «abusos d’individus i empreses aliens a la comunitat» van deixar clar que el control d’aquestes assignacions havia de ser del mateix projecte.
Greg Kroah-Hartman, responsable de les branques estables, ho va anunciar al seu blog el 13 de febrer de 2024 amb l’entrada «Linux is a CNA». Hi reconeix que considera el sistema CVE «trencat en molts aspectes», però veu el canvi com una manera d’assumir responsabilitat i preparar-se per a les lleis que comencen a exigir als projectes de codi obert que gestionin les seves vulnerabilitats. Cita curl i Python com a projectes que van fer el mateix pas per les mateixes raons.
Des d’aleshores, la documentació estableix que un CVE assignat per una altra organització a una versió suportada del kernel no s’ha de considerar vàlid, i que només els mantenidors del subsistema afectat en poden disputar o modificar un.
Un CVE per a gairebé cada correcció
La clau és en un paràgraf de cve.rst. Per la posició del kernel en el sistema, «gairebé qualsevol error podria explotar-se per comprometre’n la seguretat», però aquesta possibilitat poques vegades és evident quan es corregeix. Per això l’equip és «excessivament prudent» i assigna un CVE a qualsevol correcció que identifiqui. La mateixa documentació admet que això explica «el nombre aparentment gran de CVE» que emet.
Hi ha altres regles que convé conèixer:
- Els CVE s’assignen només quan la correcció ja és en un kernel estable, i s’identifiquen pel commit original. Res de CVE per a errors sense pedaç, tret que algú en demani un de reservat escrivint a
[email protected]. - No s’assignen CVE a versions que ja no manté l’equip d’estables i LTS. Ara mateix són la 7.3 i les longterm 6.18, 6.12, 6.6, 6.1, 5.15 i 5.10, segons kernel.org.
- Els errors que només existeixen al kernel modificat d’una distribució corresponen a aquesta distribució, no a la CNA del kernel.
- Decidir si un CVE afecta un sistema concret és cosa de qui l’utilitza. El text ho diu així: «no coneixem el teu cas d’ús ni quines parts del kernel fas servir».
Cada assignació es publica a la llista linux-cve-announce i queda registrada al repositori vulns.git de kernel.org.
Les xifres, comptades al repositori
El repositori desa un conjunt de fitxers per cada CVE publicat a cve/published/: el registre JSON, l’avís enviat a la llista i el fitxer .dyad, que indica en quines versions va aparèixer l’error i en quines es va corregir. Comptant quan va entrar cada registre a l’historial de git (dades a 2 de novembre de 2026, només els que continuen publicats):
| Any | CVE publicats |
|---|---|
| 2024 (des del febrer) | 4.287 |
| 2025 | 5.675 |
| 2026 (fins al 2 de novembre) | 8.228 |
| Total | 18.190 |
Uns altres 324 s’han rebutjat després d’assignar-se. El ritme de 2026 gairebé dobla el de l’any anterior, amb l’agost (1.643) i el setembre (2.112) com els mesos més intensos de la sèrie; el repositori no n’explica el motiu. Si es compta per l’any de l’identificador en lloc de per la data de publicació, surten 3.064 CVE-2024, 2.667 CVE-2025 i 7.971 CVE-2026, més 4.488 amb identificadors de 2019 a 2023 que corresponen a correccions antigues catalogades a posteriori, sobretot el 2024.
Les crítiques i l’efecte en les distribucions
El problema pràctic és evident: moltes eines de compliment normatiu i escàners de vulnerabilitats tracten cada CVE com una cosa que cal revisar, documentar i tancar. Amb centenars d’avisos al mes, un equip de seguretat d’empresa no els pot analitzar un per un, i les distribucions amb kernels de suport llarg han de decidir quins afecten les seves versions i quins no. Durant molt de temps els registres de la CNA tampoc no duien puntuació de gravetat, cosa que obligava cada distribució a calcular la seva.
Això darrer ha canviat en part: des de l’abril de 2026 el repositori inclou una eina per assignar puntuacions CVSS 3.1, i 6.562 CVE publicats ja tenen el seu fitxer .cvss amb la justificació de cada mètrica.
La postura de l’equip del kernel no ha canviat: el recomanable és aplicar totes les correccions d’una versió estable, perquè es proven juntes, i no triar pedaços solts. La documentació afegeix que algunes correccions rellevants poden no tenir CVE, perquè l’equip no sempre les detecta.
Com gestionar-ho com a administrador
- Segueix el kernel estable o LTS de la teva distribució i actualitza al seu ritme. És el que proposa el mateix kernel: prendre la versió completa en lloc d’avaluar CVE a CVE. Els butlletins de la distribució, com els USN del kernel d’Ubuntu, ja fan aquest filtratge per tu.
- Reserva l’anàlisi individual per al que importa: errors amb explotació pública o que toquen components que realment fas servir. Casos com Copy Fail o Dirty Frag sí que mereixen atenció immediata i, de vegades, una mitigació temporal.
- Fes servir les eines del repositori
vulns.git.bippyés la que genera els registres JSON i els avisos, idyadcalcula els parells de versió vulnerable i corregida a partir d’un commit; són més útils per entendre cada registre que per al dia a dia. Per comprovar una versió concreta és més pràcticstrak, que llista els CVE que continuen sense corregir en un commit o versió donada, icve_search, que relaciona un commit amb el seu CVE i a l’inrevés. Totes necessiten un clon local de l’arbre estable del kernel. - Desactiva el que no facis servir. Molts CVE afecten controladors o protocols que en un servidor no es carreguen mai; posar aquests mòduls en llista negra redueix de debò la superfície d’atac.
Les versions mantingudes del kernel i les seves dates són a la fitxa de Linux.
Fonts: Documentation/process/cve.rst; repositori vulns.git de la CNA del kernel (recompte propi a 2-nov-2026); arxiu de linux-cve-announce; «Linux is a CNA», de Greg Kroah-Hartman; versions mantingudes a kernel.org.