EN
en direct
CVE-2026-65660 · Microsoft SharePoint · CVSS 8.8 CVE-2026-67279 · MikroTik RouterOS CVE-2026-87902 · WordPress Core CVE-2026-5430 · WSO2 Multiple Products · CVSS 10
Linux Élevée CVSS 8.6

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

Entre le 23 et le 29 août 2026, le projet Linux a publié 227 CVE, cinq fois une semaine normale, quand un cycle stable complet a atterri le 28 août sur les huit branches actives. Mettez à jour vers la dernière version de votre branche, mais traitez séparément quatre failles qu’aucun correctif stable ne couvre encore.

WE Walid ETTAYEB · Fondateur 29 août 2026 · 6 min
Une plaquette de silicium sombre couverte de puces identiques, une seule puce marquée d’un point ambre.

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.
bash 
# 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

cve

Vulnérabilités liées

CVE-2026-80590In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: <TASK> __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 </TASK> Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list") and by commit 9e4b7a99a03a ("net: gso: fix panic on frag_list with mixed head alloc types") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 ("tun: Allow GSO using virtio_net_hdr"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged. Élevée CVSS 8.6 28/08 CVE-2026-80635In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix OOB read from short trigger BA firmware response The firmware response length is only checked against sizeof(*rsp) (20 bytes), but when candidate_cnt >= 1, a 22-byte candidate struct is read at buf + 20 without verifying the response contains it. This causes an out-of-bounds read of stale heap data, corrupting the BA session state. Add validation that the response includes the candidate data. Élevée CVSS 8.8 28/08 CVE-2026-74743In the Linux kernel, the following vulnerability has been resolved: macvlan: inherit needed_headroom and needed_tailroom from lowerdev macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. Critique CVSS 9.8 26/08 CVE-2026-74752In the Linux kernel, the following vulnerability has been resolved: sctp: validate cookie AUTH state before use When cookie authentication is disabled, COOKIE_ECHO restores fixed-size AUTH fields directly from peer-controlled cookie bytes. A forged RANDOM length, HMAC list, or CHUNKS list can then reach association consumers with lengths or identifiers that were never validated against the local backing arrays. A forged RANDOM length can cause out-of-bounds reads during key-vector construction. A forged HMAC identifier also caused a 32-byte write past a zero-length AUTH chunk, providing a primitive for a local privilege escalation chain. Validate the cookie's RANDOM, HMACS, and CHUNKS parameters at the cookie trust boundary before copying them into the association. Reject invalid types, malformed lengths, unsupported HMAC identifiers, HMAC lists without SHA1, and forbidden chunk ids. Critique CVSS 9.8 26/08 CVE-2026-80551In the Linux kernel, the following vulnerability has been resolved: s390/vfio_ccw: Ensure first IDAW remains constant The first IDAW in a list does not need to be on a 2K/4K boundary like all others, and so is read separately to accurately calculate the size of the buffer needed to read the full IDAL. Verify that the address found in the first IDAW is unchanged between reads, to ensure a consistent set of IDAWs being worked with. Critique CVSS 9.3 26/08
linux-kernel cve-2026-80590 cve-2026-74752 lts triage-cve

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

Quatre exploits publics transforment un compte Linux ordinaire en root, via des bugs vieux de 21 ans

Le 18 septembre 2026, le chercheur Asim Manizada publie des exploits fonctionnels pour quatre failles du noyau Linux — DirtyAH6, TUNderflow, PPPoEject et DiagSpill — qui donnent root à tout utilisateur local. Les correctifs existent depuis plusieurs semaines, alors vérifiez la version de votre noyau et restreignez les user namespaces non privilégiés sans attendre.

WE Walid ETTAYEB 28 septembre 2026 · 6 min
← Retour au fil

Tapez au moins deux caractères.

↑ ↓ naviguer ↵ ouvrir esc fermer