# L'allau de CVE del kernel Linux: com treballa la seva CNA i per què n'hi ha més de 18.000

- **Publicat el:** 2026-11-10
- **Categoria:** Seguretat
- **Pàgina original:** https://linuxgratis.com/ca/articles/cve-kernel-linux-allau-cna

Des del febrer de 2024 el mateix kernel Linux assigna els seus CVE i en posa un a gairebé cada correcció que arriba a un kernel estable. Hem comptat els registres del seu repositori vulns: 4.287 el 2024, 5.675 el 2025 i 8.228 el que portem de 2026. Què vol dir per a les distribucions i com gestionar-ho sense revisar CVE a CVE.

---

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 `cve@kernel.org`.
- 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](https://www.kernel.org/releases.html).
- 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](/ca/articles/usn-8059-kernel-linux-febrero-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](/ca/articles/cve-2026-31431-copy-fail-algif-aead-privesc-root-kernel-linux) o [Dirty Frag](/ca/articles/dirty-frag-kernel-linux-escalada-privilegios-mitigacion) 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, i `dyad` calcula 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àctic `strak`, que llista els CVE que continuen sense corregir en un *commit* o versió donada, i `cve_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](/ca/linux-kernel).

**Fonts:** [Documentation/process/cve.rst](https://docs.kernel.org/process/cve.html); [repositori vulns.git](https://git.kernel.org/pub/scm/linux/security/vulns.git/) de la CNA del kernel (recompte propi a 2-nov-2026); [arxiu de linux-cve-announce](https://lore.kernel.org/linux-cve-announce/); [«Linux is a CNA»](http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/), de Greg Kroah-Hartman; [versions mantingudes a kernel.org](https://www.kernel.org/releases.html).