Linux · 20 août 2026
Des correctifs du noyau AlmaLinux 8 déployés pour CVE-2026-17523
AlmaLinux a publié le 18 août 2026 de nouvelles mises à jour de sécurité du noyau et de kernel-rt pour AlmaLinux 8, et la raison concrète de s'y intéresser est CVE-2026-17523 : une faille dans le sous-système CAN BCM de Linux, décrite par les sources éditeur et de suivi des vulnérabilités comme une voie locale vers l'exécution de code au niveau du noyau et l'élévation de privilèges. Ce n'est pas en soi une urgence sur un service exposé à distance, mais c'est exactement le type de bug noyau qui compte sur les hôtes partagés, les workers CI, les postes de développement, les bastions, les hôtes de virtualisation, et tout serveur où un compte à faibles privilèges fait encore partie de votre modèle de menace.
Cette mise à jour rappelle aussi une règle d'exploitation ennuyeuse mais essentielle : un avis de sécurité noyau n'est « traité » qu'une fois le noyau corrigé installé et réellement en cours d'exécution sur la machine. Les scanners de paquets, les tableaux de bord de mise à jour et la sortie de dnf update sont utiles, mais ils ne prouvent pas que l'ancien noyau a disparu de la mémoire. Pour les parcs qui font tourner AlmaLinux 8, des reconstructions de type RHEL, ou des images Linux d'entreprise mixtes, cela doit entrer dans la prochaine fenêtre de maintenance avec une vérification explicite du redémarrage.
Ce qui a changé
L'index des mises à jour de sécurité du 18 août de LWN référence l'avis AlmaLinux ALSA-2026:55764 pour le kernel d'AlmaLinux 8 et ALSA-2026:55765 pour kernel-rt d'AlmaLinux 8, tous deux datés du 2026-08-18. L'annonce AlmaLinux relayée par LWN qualifie ALSA-2026:55764 de mise à jour de sécurité, de correctifs de bugs et d'améliorations noyau de niveau Important pour AlmaLinux 8.
L'avis noyau inclut plusieurs correctifs, mais CVE-2026-17523 est celui que je placerais en tête d'une note de correctifs SRE. Dans le texte de l'annonce AlmaLinux, il est résumé comme un problème can:bcm pouvant mener à une exécution de code arbitraire au niveau du noyau et à une élévation de privilèges. La fiche du plugin Tenable pour l'avis correspondant kernel-rt d'AlmaLinux 8 liste indépendamment le même CVE dans l'ensemble corrigé, et indique que le contrôle local recherche les mises à jour de sécurité AlmaLinux manquantes.
L'entrée Bugzilla de Red Hat pour CVE-2026-17523 relie le problème au chemin du Broadcast Manager CAN de Linux et renvoie vers les errata produit Red Hat correspondants pour RHSA-2026:55764 et RHSA-2026:55765. La base de données de vulnérabilités de SentinelOne apporte un cadrage technique indépendant utile : la zone affectée est l'implémentation du Broadcast Manager CAN (Controller Area Network) du noyau, l'exploitation nécessitant un accès local et la capacité de créer des sockets CAN BCM.
Pourquoi c'est important pour les ingénieurs sur le terrain
Les bugs d'élévation de privilèges locale sont souvent sous-priorisés parce qu'ils ne sont pas exposés directement à internet. C'est généralement le mauvais modèle mental. La question n'est pas « ce chemin du noyau est-il atteignable directement depuis internet ? ». La bonne question est « où autorisons-nous du code non fiable ou semi-fiable à s'exécuter ? ».
Cette liste est plus longue que ne l'admettent la plupart des inventaires. Les runners CI exécutent du code de pull request. Les hôtes de build décompressent des dépendances et lancent des suites de tests. Les bastions et postes d'administration accumulent des comptes shell. Des serveurs applicatifs multi-tenant existent parfois encore. Les comptes d'automatisation internes ont souvent plus d'accès au système de fichiers qu'ils ne le devraient. Un bug d'élévation de privilèges locale transforme toutes ces situations en frontières bien plus sérieuses.
CVE-2026-17523 mérite une attention particulière car elle se situe dans un sous-système auquel beaucoup d'équipes serveur ne pensent pas : le réseau CAN. Le CAN est courant dans l'automobile, l'industriel, l'embarqué et les environnements de laboratoire de test, mais les modules noyau et les familles de sockets correspondants peuvent aussi exister sur des distributions généralistes. Si un hôte n'utilise pas intentionnellement le CAN, la bonne réponse opérationnelle n'est pas seulement « corriger » ; c'est aussi « vérifier si ce chemin de code est chargeable ou déjà chargé ».
Ce que cela change en pratique
Pour les parcs AlmaLinux 8, traitez ALSA-2026:55764 et ALSA-2026:55765 comme une campagne de redémarrage noyau, pas comme une mise à jour de paquet en arrière-plan. La présence du paquet corrigé sur le disque ne suffit pas. Il faut que le noyau corrigé soit effectivement démarré.
Un runbook pratique devrait ressembler à ceci :
# Voir les avis de sécurité pertinents connus de dnf
sudo dnf updateinfo list --security | grep -E 'ALSA-2026:55764|ALSA-2026:55765|kernel'
# Appliquer les mises à jour du noyau
sudo dnf update --security kernel\* kernel-rt\*
# Redémarrer dans votre processus de maintenance habituel
sudo systemctl reboot
# Après le redémarrage, vérifier ce qui tourne réellement
uname -r
rpm -q kernel kernel-core kernel-modules 2>/dev/null | sort
rpm -q kernel-rt kernel-rt-core kernel-rt-modules 2>/dev/null | sort
Si vous utilisez le live patching, ne présumez pas de la couverture. Les produits de correctifs à chaud du noyau varient selon la distribution, la branche de noyau, le CVE et la famille de paquets. Vérifiez le mapping des avis du fournisseur de live patching pour CVE-2026-17523, et planifiez tout de même un redémarrage normal si votre processus de conformité ou de réponse à incident exige que le paquet noyau de base soit avancé.
Pour les équipes infrastructure, j'ajouterais aussi une vérification rapide d'exposition CAN au même ticket :
lsmod | grep -E '^can|^can_bcm|^vcan'
modprobe --show-depends can-bcm 2>/dev/null || true
find /etc/modules-load.d /usr/lib/modules-load.d -type f -maxdepth 1 -print -exec grep -H 'can' {} \; 2>/dev/null
Ne considérez pas un résultat lsmod vide comme un substitut au correctif. Cela aide seulement à comprendre l'exposition et à prioriser les hôtes suspects. Les modules peuvent être chargés plus tard si la politique le permet.
Notes de parc
Pour les environnements fortement conteneurisés, rappelez-vous que les conteneurs partagent le noyau de l'hôte. Reconstruire les images applicatives ne corrige pas une vulnérabilité du noyau hôte. Mettre à jour l'image de base dans un Dockerfile ou une charge de travail Kubernetes peut être une bonne hygiène, mais cela ne remplace pas la mise à jour et le redémarrage du nœud.
Pour les nœuds Kubernetes ou Nomad, videz le nœud avant de redémarrer et vérifiez qu'il revient avec le noyau attendu :
kubectl drain NODE --ignore-daemonsets --delete-emptydir-data
# corriger et redémarrer le nœud
kubectl uncordon NODE
kubectl get nodes -o wide
Pour les groupes en autoscaling, la voie la plus propre est généralement de préparer une nouvelle image machine, de faire tourner le groupe (rolling), puis de terminer les anciennes instances. Cela donne un artefact reproductible et évite un état de correctifs bricolé au cas par cas.
Pour les systèmes CI, priorisez les runners partagés avant les postes individuels. Un runner qui exécute du code de branche non fiable est une meilleure cible qu'un serveur verrouillé sans utilisateur shell. Si vous autorisez les conteneurs privilégiés, les montages du socket Docker, la virtualisation imbriquée ou un accès large aux périphériques, augmentez encore la priorité.
Réserves
Je n'ai pas trouvé suffisamment de détails publics de source primaire pour affirmer une exploitation active à partir de ces sources. La fiche Tenable indique que son contrôle s'appuie sur des versions de paquets auto-déclarées, ce qui est normal pour des contrôles de paquets Linux authentifiés, mais à garder à l'esprit lors du triage des résultats de scanner. La page de vulnérabilité de SentinelOne est une analyse indépendante utile, mais ce n'est pas un avis de distribution ; pour le statut exact des paquets, utilisez les données d'errata d'AlmaLinux, de Red Hat ou de votre fournisseur.
L'affirmation la plus sûre est plus étroite et reste opérationnellement importante : AlmaLinux 8 a publié des mises à jour noyau de niveau Important le 18 août 2026 ; ces mises à jour incluent CVE-2026-17523 ; le problème est décrit par plusieurs sources comme une voie d'élévation de privilèges locale impliquant CAN BCM ; et les hôtes affectés ont besoin de noyaux mis à jour ainsi que d'une vérification du redémarrage.
Sources
Notes connexes
Nginx · 21 août 2026
Ubuntu annule à nouveau son correctif nginx pour CVE-2026-42533
Ubuntu a brièvement re-corrigé puis à nouveau annulé un correctif CVE de nginx. Traitez les hôtes LTS concernés comme un chantier de validation et d'atténuation.
AI · 22 août 2026
OpenAI maintient la ZDR pour son API de pointe
La rétention nulle des données (ZDR) d'OpenAI pour ses modèles de pointe transforme la politique de rétention en décision d'architecture pour l'IA en entreprise.