Le noyau Linux publie 227 CVE en une semaine et laisse quatre failles sans correctif sur les anciennes branches

28 août 2026. Greg Kroah-Hartman publie d’un coup huit noyaux stables. 23 au 29 août 2026. Le projet Linux émet 227 CVE, soit environ cinq fois une semaine ordinaire. 16 août 2026. La branche 7.2 sort de mainline et reçoit déjà son deuxième correctif. La nouvelle n’est pas une faille spectaculaire : c’est un changement d’échelle dans la façon dont le noyau publie ses vulnérabilités — et dans la façon dont les équipes doivent les traiter.

Pourquoi 227 CVE d’un coup

Le chiffre surprend, mais la cause est administrative plutôt que technique. Les identifiants le racontent : 21 CVE appartiennent au bloc CVE-2026-747xx, les 206 autres au bloc CVE-2026-805xx à 807xx. Le 28 août, le projet a coupé une nouvelle version point release sur chaque branche active en même temps, et les fiches de tout ce qui est entré dans ces versions ont été publiées ensemble.

La semaine précédente, la même série de veille ne comptait que six CVE. Le saut à 227 ne signale donc pas un effondrement de la qualité du noyau : il reflète le rythme d’un cycle stable complet. La plupart des correctifs sont étroits — un dépassement de buffer ici, une validation manquante là. Presque aucun ne se ressemble, et presque tous sont déjà dans les noyaux publiés le jour même.

Deux nuances comptent avant de paniquer. D’abord, aucune de ces 227 failles n’est signalée comme exploitée, et aucun exploit public n’avait été trouvé au moment de la publication. Ensuite, le NVD n’a pas fini d’analyser ce lot : les scores CVSS cités ici sont ceux du CNA du noyau, portés comme métrique secondaire. D’autres éditeurs et bases d’enrichissement publieront des chiffres différents. Priorisez par accessibilité et par contexte de déploiement, pas par le seul score.

CVE-2026-80590, la faille qui a dicté les huit correctifs

Un seul enregistrement, CVE-2026-80590, fixe à lui seul la cible des huit branches stables. La faille laisse un état GSO périmé sur des fragments IPv4 avant leur réassemblage : un utilisateur sans privilège peut marquer des fragments comme GSO et provoquer un panic du noyau. C’est un déni de service local, mais un déni de service qui emporte l’hôte entier.

Le détail qui compte est ailleurs : CVE-2026-80590 n’est corrigée que dans les branches stables et ne mentionne aucune entrée mainline. C’est elle, en pratique, qui explique les chiffres de la semaine. Deux autres fiches n’ont pas non plus de correctif mainline : CVE-2026-80724 et CVE-2026-74753.

Pour les administrateurs, la conséquence est limpide. Les huit versions cibles — 5.10.268, 5.15.219, 6.1.186, 6.6.155, 6.12.107, 6.18.48, 7.1.12 et 7.2.2 — sont toutes les plus récentes de leur branche, et toutes ont été coupées le 28 août. Sur un noyau upstream, le test est binaire : si vous n’êtes pas sur la dernière version de votre branche, vous êtes en retard.

Quatre failles que la mise à jour de branche ne couvre pas

C’est la partie à lire avant de fermer le ticket. Quatre fiches marquent une branche comme affectée sans nommer de version corrigée pour elle. Installer la cible du tableau ne les corrige donc pas.

• CVE-2026-74752 (SCTP, CVSS 9,8) : introduite en 2.6.24, corrigée seulement en 7.1.10 et en mainline 7.2. Aucun correctif nommé pour 5.10, 5.15, 6.1, 6.6, 6.12 ni 6.18. C’est l’écart le plus large de la semaine.
• CVE-2026-80551 (s390 vfio-ccw, CVSS 9,3) : introduite en 5.3, corrigée en 6.6.154 et au-delà. Aucun correctif pour 5.10, 5.15 ni 6.1.
• CVE-2026-74743 (macvlan, CVSS 9,8) : introduite en 2.6.23, corrigée en 6.1.184 et au-delà. Aucun correctif pour 5.10 ni 5.15.
• CVE-2026-80635 (Wi-Fi wcn36xx) : introduite en 4.7, corrigée en 6.1.178 et au-delà. Aucun correctif pour 5.10 ni 5.15.

Ajoutez à cela la CVE-2026-74582 de la semaine dernière, toujours non corrigée sur 5.10, 5.15 et 6.1. Une équipe qui livre l’une des anciennes branches LTS a donc désormais cinq éléments à suivre séparément du simple changement de version.

Le pattern est parlant : plus la branche est vieille, plus elle accumule de failles que le flux stable ne rattrape plus. Ce n’est pas de la négligence — c’est le coût d’une branche en fin de vie, où chaque backport coûte de plus en plus cher à produire.

Comment trier 227 CVE sans y passer la semaine

La méthode tient en trois gestes, dans l’ordre.

• Vérifier la version. uname -r, puis comparer à la cible de sa branche. Tout est déjà sorti : rien n’attend une version future.
• Confirmer que la fonctionnalité est compilée et atteignable. Chaque bug est barré par une option de configuration : CONFIG_IP_SCTP, CONFIG_MACVLAN, CONFIG_WCN36XX, CONFIG_VFIO_CCW, CONFIG_MAC80211, etc. Un symbole à m reste présent et chargeable, pas absent.
• Pousser le bon noyau. Appliquer la dernière version upstream de sa branche, ou un backport fournisseur vérifié, équivalent à la cible.

# Version actuelle du noyau
uname -r

# La fonctionnalité vulnérable est-elle compilée ou chargeable ?
grep -E 'CONFIG_(IP_SCTP|MACVLAN|WCN36XX|VFIO_CCW)' /boot/config-$(uname -r)

Sur un noyau fournisseur ou BSP, la version ne se compare pas proprement au tableau. Un noyau qui affiche 5.10.110-rk3588 est basé sur 5.10.110 et ne deviendra jamais 5.10.268 par une mise à jour upstream. Pour ces produits, le tableau dit quels correctifs doivent être présents, pas quelle version installer. Interrogez le fournisseur du silicium, et traitez un backport vérifié comme équivalent à la cible.

Ce que ce volume change pour la maintenance

Ce n’est pas la première fois que le noyau publie un gros lot, mais l’ampleur change la pratique. Une équipe qui suivait encore les CVE une par une — lire la fiche, juger si elle s’applique, chercher le commit — est noyée à 227 en une semaine. Le modèle des branches stables apporte une réponse mécanique : pour l’immense majorité des failles, le correctif est déjà dans la dernière version point release de la branche. Mettre à jour la version règle donc le lot d’un coup, sans backport manuel.

Le corollaire est tout aussi important. Si une équipe ne peut pas mettre à jour — noyau verrouillé, certification, BSP fournisseur — le volume devient ingérable, car chaque backport individuel est un travail de portage et de validation à part entière. C’est là que les quatre failles sans correctif changent de nature : sur une vieille LTS, la mise à jour de branche ne les couvre pas, et il faut décider, une par une, si le risque justifie un backport que le flux stable n’a pas fourni. Le vrai coût de la maintenance d’une branche en fin de vie n’est plus le correctif — c’est le tri.

La bonne nouvelle est que le noyau a rendu le suivi transparent : les fiches sont publiées sur la liste linux-cve-announce, consultables sur lore.kernel.org, et chaque version stable documente les correctifs qu’elle embarque. L’information est là ; ce qui manque encore aux équipes, c’est le réflexe de patcher par version de branche plutôt que par CVE.

Verdict

Si vous êtes sur un noyau upstream récent, la mise à jour vers la dernière version de votre branche règle l’essentiel : 227 CVE, dont CVE-2026-80590, sont déjà corrigées dans les huit cibles publiées le 28 août. Faites-le avant la prochaine fenêtre de maintenance, et la grande majorité du lot est réglée.

Si vous livrez une ancienne branche LTS — 5.10, 5.15 ou 6.1 — ou un noyau BSP fournisseur, la mise à jour ne suffit pas : quatre failles de cette semaine, plus une de la précédente, restent sans correctif. Suivez-les explicitement, chiffrez le risque résiduel, et posez la vraie question à votre fournisseur : la branche mérite-t-elle encore d’être maintenue, ou est-il temps de planifier la migration vers une LTS plus récente ?

Références

• Stable releases 7.2.2, 7.1.12, 6.18.48, 6.12.107, 6.6.155, 6.1.186, 5.15.219, 5.10.268 — LWN.net, 28 août 2026
• Linux Kernel CVEs to Patch by Device: 23–29 Aug 2026 — TechVeda, 29 août 2026
• CVE-2026-80590 — CVE.org
• CVE-2026-74752 (SCTP cookie AUTH) — CVE.org
• CVE-2026-80551 (s390 vfio-ccw) — CVE.org
• CVE-2026-74743 (macvlan) — CVE.org
• CVE-2026-80635 (wcn36xx Wi-Fi) — CVE.org
• kernel.org — active releases
• linux-cve-announce, 23 au 29 août 2026 — lore.kernel.org