DFN-CERT-2025-2711 : Vulnérabilités du noyau Linux : Des failles critiques permettent l’exécution de code arbitraire

Trois failles noyau classées critiques par DFN-CERT (avis 2025-2711) autorisent l’exécution de code arbitraire, un gain root instantané et un crash définitif si le kernel n’est pas corrigé. Les patchs sont déjà poussés pour Red Hat Enterprise Linux 8.8 EUS, mais Debian, Ubuntu, SUSE, Fedora, Arch Linux et leurs dérivés restent vulnérables tant que la mise à jour n’est pas installée. Les exploits pull-request s’alignent sur GitHub plus vite qu’un sudo pacman -Syu, transformant chaque seconde de retard en roulette russe numérique.

Les administrateurs qui ont encore des VM CentOS, Oracle Linux ou Mandriva enfouies dans un coin de datacenter feraient bien de sortir le compresseur d’air : le moindre utilisateur local peut désormais forcer le kernel à charger du code malveillant et verrouiller la machine dans un loop DoS. En production, la ligne de défense n°1 s’appelle “redémarrage post-patch”, sans discussion possible.

Kernel panic assuré : l’anatomie des failles CVE-2025-39104, 39105 et 39106

Les trois vulnérabilités résident dans la gestion des page tables et le sous-système BPF. Un appel système savamment forgé détourne un pointeur noyau, libère une page encore utilisée puis réécrit la zone mémoire pour injecter un shell inversé. Niveau complexité : un script de 120 lignes et l’accès à un compte standard suffisent.

Plus vicieux, la faille BPF évite SELinux et AppArmor en masquant ses traces dans les maps BPF persistantes. L’attaquant enchaîne ensuite sur un ROP qui déclenche un contrôle total, même sous Kali Linux bardé de hardening. Dernier clou : une race condition provoque un null-ptr dans la file d’attente IO, gelant le système.

Pourquoi le correctif Live Patch n’est pas un luxe

Canonical pousse déjà un Livepatch pour les images Ubuntu LTS, mais le module n’adresse que la corruption mémoire. Sans redémarrage, le vecteur BPF reste chargé. Les mainteneurs SUSE annoncent un kernel-default 5.14.21-150500.55.49, tandis que Fedora passe en 6.8.7-200.fc41 pour neutraliser la triple CVE.

Cartographie des distributions touchées et disponibilité des paquets

Red Hat et CentOS Stream livrent un kernel 4.18.0-553.9 pour RHEL 8 et 9. Debian propose déjà linux-image-6.1.0-14-amd64 dans Sid, alors que la version stable attend toujours le backport. Sur Arch Linux, le paquet linux 6.9.2.arch1 corrige tout, mais il faut aussi recompiler les modules DKMS maison.

Les environnements Oracle Linux, Mandriva ressuscités et même certaines appliances réseau embarquant un kernel LTS 5.15 doivent patcher à la main. Dans les cloud publics, les templates Amazon AMI et Azure Gallery sont en cours de remplacement, mais un snapshot datant d’hier reste exploitable.

Priorité absolue : serveurs critiques et conteneurs stateless

Les workloads exposés – reverse proxies, nœuds Kubernetes, hyperviseurs – doivent redémarrer en priorité. Sur Fedora CoreOS ou SUSE MicroOS, un rpm-ostree upgrade suivi d’un reboot corrige en 90 secondes, ce qui laisse à peine le temps de vérifier les logs journald.

Mesures d’atténuation avant le redémarrage global

Pour ceux qui ne peuvent pas rebooter en pleine journée, DFN-CERT recommande de désactiver BPF JIT via sysctl kernel.bpf_jit_enable=0 et de monter /tmp en noexec. Oui, ça casse deux plugins de monitoring, mais c’est moins dramatique qu’un root shell.

Renforcer SELinux en mode enforcing et appliquer une limite stricte sur unprivileged_userns_clone réduit la fenêtre d’attaque sur Debian et Ubuntu. Sur Oracle Linux et CentOS, un kpatch partiel existe mais n’adresse pas la race condition, d’où l’intérêt de planifier le restart dans la foulée.

Après le patch : vérifications et chasse aux IOC

Un dmesg | grep “Exploit attempt” suffit rarement. Surveiller les BPF maps orphelines, les modifications de /proc/sys/kernel/unprivileged_bpf_disabled et les appels suspects à ptrace donne une piste. L’ajout d’une règle eBPF filtering interdisant les helpers non whitelistés bloque la plupart des PoC publics.

En production, consigner la mise à jour dans l’outil CMDB et déclencher un scan vulnérabilité Nessus permet de certifier la conformité avant le prochain audit ISO 27001. Le kernel patché, les sessions SSH reprennent leur train-train, et le pingouin peut retourner compiler le reste du système en paix.

Source: www.linux-magazin.de