Quotidien suisseDimanche 4 octobre 2026Édition de 13h, technologie
Prochaine publication le 4 octobre 2026 à 17h
Une · Noyau · Sécurité
Linux : sept stables en un jour (7.2.9 → 5.10.271)
Le 3.10, Greg Kroah-Hartman signe sept sorties stables en moins de vingt minutes : 7.2.9, 6.18.55, 6.12.112, 6.6.158, 6.1.189, 5.15.222 et 5.10.271. Les tarballs, signatures PGP et ChangeLogs sont sur kernel.org ; les dépôts des distributions devraient suivre dans les jours qui viennent. Lot dominé par des correctifs de sûreté mémoire (use-after-free, hors-limites), souvent issus de fuzzers (syzbot) et d’outils d’analyse assistés.
Sur 7.2.9 (première point-release de la ligne 7.x) : durcissement KVM (virtualisation imbriquée), use-after-free conntrack côté ordonnancement réseau, correctifs XFS. Sur 6.18.55 (longterm récent) : crash BPF lié à un type BTF sans clé dans une hash map, et correctif du stack ROSE (boucle de routage). Virtualisation, netfilter et systèmes de fichiers concentrent une part notable du volume. Pas de détail d’exploitation ici.
Périmètre : desktops et serveurs sur 6.x/7.x gagnent à monter ; les arbres longterm (5.10 à 6.18) permettent de rester sur une série certifiée ou figée. Distros (Debian, Fedora, RHEL, Ubuntu, etc.) consomment ces branches. Fil : annonces LKML / kernel.org, 3.10.
Le 2.10, Microsoft publie CVE-2026-96940 : autorisation trop faible dans Exchange Server permettant à un attaquant authentifié d’élever ses privilèges sur le réseau (CVSS 3.1 base 8.8, vecteur AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Impact typique signalé : accès à des boîtes d’autres utilisateurs de la même organisation. Exchange Online est indiqué comme déjà couvert ; le correctif vise les déploiements on-premises.
Correctifs V2 cités pour les branches courantes : Exchange SE RTM (KB5129955), Exchange 2019 CU15/CU14 (KB5129956 / KB5129957), Exchange 2016 CU23 (KB5129958). Les mises à jour de septembre ne remplacent pas ce lot. Consigne : installer le correctif adapté, redémarrer, vérifier les services. Pas de PoC ici ; pas de signalement public d’exploitation active au moment de la publication CVE.
Le 1.10, Canonical publie la beta d’Ubuntu 26.10 (Desktop, Server, WSL, Cloud et flavors). Sortie finale prévue le 15.10. Images beta : noyau Linux 7.3 en release candidate (cible finale 7.3), GNOME 51, Mesa 26.2, bascule complète des coreutils vers l’implémentation Rust (uutils), remplacement de dbus-daemon par dbus-broker.
Toolchain annoncée : GCC 16, Python 3.14, Rust 1.97, OpenJDK 27 ; GStreamer 1.30. Côté bureau : réordonnancement des frames dans Mutter, captures moins coûteuses, luminosité d’écran mémorisée. Beta destinée aux tests, pas à la production ; les ISOs et notes sont sur cdimage / documentation.ubuntu.com. Flavors (Kubuntu, Xubuntu, Lubuntu, etc.) suivent le même jalon.
Arbres stable et longterm : pourquoi sept sorties le même jour
L’une du jour (sept stables signées le 3.10) illustre le modèle de maintenance du noyau Linux. Atelier pédagogique sur mainline, stable et longterm — pas un guide d’exploitation.
Mainline ≠ ce que tourne votre serveur. Linus Torvalds coupe une série (~9–10 semaines) : merge window, puis rc1…rcN, puis une sortie « stable » (ex. 7.2). Dès qu’une série est publiée, elle entre dans le circuit de Greg Kroah-Hartman : correctifs de bugs et de sécurité sont backportés depuis le mainline vers chaque branche encore maintenue. Le numéro .N (7.2.9, 6.12.112…) est une point-release de cette branche, pas une nouvelle génération de fonctionnalités.
Stable vs longterm. Une branche « stable » récente reçoit des correctifs tant qu’elle est suivie ; les « longterm » (LTS) — ici jusqu’à 5.10.271 — restent vivantes des années pour l’embarqué, le certifié et les distros qui figent une ABI/API noyau. Le jour « release day », Greg publie souvent toutes les branches encore supportées d’un coup : d’où sept tarballs en ~18 minutes le 3.10. Les distros n’inventent pas leurs CVE noyau : elles emballent ces mêmes commits.
Lire un ChangeLog. Les motifs use-after-free / OOB / NULL deref dominent parce que ce sont les classes qui font panic ou élévation locale. Les attributions syzbot / « Assisted-by: LLM » disent d’où viennent les rapports ; la revue humaine et les Tested-by restent le filtre. Pour un admin : identifier quelle branche votre distro suit (uname -r), attendre le paquet security, redémarrer sur le nouveau noyau. Atelier pédagogique, pas un guide d’exploitation.
Sortie trimestrielle signalée vers le 1–2.10 : Coreboot 26.09 construit en C23 ; port Framework Laptop 12 (Core 13e gén.) ; bring-up AMD EPYC Turin / openSIL (carte GIGABYTE MZ33-AR1) ; nombreux Chromebooks Google. Politique revue : commentaires d’agents IA uniquement, préfixe « [AI-generated] », pas d’ouverture d’issues de premier niveau par l’IA. Fil : Phoronix / coreboot.org.
Arm : patches Linux « TLBID » (invalidation TLB ciblée)
Vers le 3.10, Arm envoie un premier lot pour supporter les TLBI Domains dans le noyau : invalider le TLB seulement sur le sous-ensemble de cœurs où un processus a tourné, plutôt que système entier. Visé : serveurs Arm à fort nombre de cœurs. Pas encore dans l’Architecture Reference Manual ; dépend aussi de LLVM ≥23 ou Binutils ≥2.46. Pas de chiffres de perf publiés.
