Noyau Linux 7.2 en fin de vie : plus aucun correctif de sécurité, migrez vers 7.3

Le noyau Linux (kernel) est le coeur du système d'exploitation sur tout serveur Unix : il gère la mémoire RAM, les processeurs, les systèmes de fichiers, la pile réseau et le firewall. Greg Kroah-Hartman a publié le noyau Linux 7.2.15 le 1er novembre 2026 : c'est la dernière version de la série 7.2. La branche est désormais marquée EOL (End of Life) sur kernel.org. Concrètement, plus aucun correctif de sécurité ni patch de stabilité ne sera publié pour le noyau 7.2. Si votre VPS Linux ou votre serveur dédié tourne encore sous un noyau 7.2.x, il est temps de planifier la migration vers la nouvelle version stable 7.3.y ou d'attendre le futur noyau 7.4.

Source : annonce de fin de vie du noyau Linux 7.2, LWN.net, 1er novembre 2026.

Vérifier la version du noyau Linux sur votre serveur

Avant toute décision, identifiez le noyau en cours d'exécution. Ouvrez un terminal et connectez-vous en SSH à votre serveur. Exécutez cette commande en ligne de commande :

uname -r

La commande affiche la version exacte du noyau, par exemple 7.2.14-generic. Si le numéro commence par 7.2, votre serveur est concerné par cette fin de support. Pour lister tous les paquets noyau (packages kernel) installés sur Ubuntu ou Debian :

dpkg --list | grep linux-image

Sur CentOS, AlmaLinux ou Rocky Linux, listez les paquets kernel installés avec :

rpm -qa | grep kernel

Sur un serveur dédié sous Proxmox VE, le noyau utilisé est celui du noeud hôte, pas celui des machines virtuelles. Vérifiez le noyau directement sur l'hyperviseur depuis le terminal. Sur un VPS hébergé en virtualisation KVM, le noyau est celui de votre distribution : la commande uname -r reste la bonne méthode. Ce guide concerne les VPS et serveurs dédiés ; les Raspberry Pi et les postes desktop Linux suivent d'autres canaux de mise à jour.

Ce que le noyau gère sur votre serveur

Le noyau Linux est la couche logicielle entre le matériel et le système d'exploitation. Il contrôle directement :

• Les processeurs (CPU) : planification des processus sur chaque core, répartition de la charge entre les coeurs physiques et virtuels. Un bug dans l'ordonnanceur du noyau dégrade les performances de tous les services qui tournent sur le serveur : Nginx, Apache, MySQL, PostgreSQL, serveur de jeu, scripts d'automatisation.
• La mémoire RAM : allocation, swap, OOM killer. Si vous avez configuré le swap sur votre VPS, c'est le noyau qui décide quand l'utiliser. Un bug noyau dans la gestion mémoire peut provoquer des lenteurs ou des arrêts de processus sans avertissement.
• Le réseau et le firewall : Netfilter, nftables et iptables sont des modules noyau. Chaque règle de pare-feu que vous configurez sur votre serveur dépend du kernel. Un noyau obsolète peut contenir des failles dans la pile réseau, exposant vos services DNS, FTP, SSH et vos scripts d'automatisation Python ou Bash.
• La virtualisation : KVM, le module de virtualisation intégré au noyau Linux, permet à un serveur dédié d'héberger des machines virtuelles. Proxmox VE, QEMU et Docker s'appuient sur des fonctionnalités noyau (namespaces, cgroups) pour l'isolation des conteneurs et des VM.
• Les systèmes de fichiers : ext4, XFS, Btrfs. Les correctifs noyau corrigent des bugs de corruption de données et améliorent les performances d'écriture disque. Un backup régulier reste indispensable, mais un noyau maintenu réduit le risque de perte de données.
• Le boot et les pilotes : le noyau charge les pilotes matériels au démarrage via le bootloader GRUB. Un noyau incompatible avec votre matériel peut empêcher le boot du serveur.

Un noyau en fin de vie signifie que tous ces sous-systèmes ne reçoivent plus de correctifs de bugs ni de patchs de sécurité. Les conséquences touchent l'ensemble du serveur, pas uniquement le kernel.

Pourquoi la série 7.2 a été arrêtée plus tôt que prévu

Les noyaux Linux stables ne sont pas tous maintenus la même durée. Certaines versions dites LTS (Long Term Support) sont supportées plusieurs années (les séries 5.10, 5.15, 6.1, 6.6, 6.12, 6.18), tandis que les versions stables régulières ne reçoivent des correctifs que jusqu'à la sortie du noyau stable suivant.

Dans le cas du noyau 7.2, Greg Kroah-Hartman a expliqué que maintenir cette branche plus longtemps aurait obligé l'équipe à gérer huit branches actives simultanément : « it would require us to keep 8 different branches alive at the same moment, a taxing task under the best of times ». Plutôt que de diluer l'effort sur huit séries, la décision a été de concentrer les ressources sur la dernière branche stable, 7.3.y, et sur les branches LTS antérieures.

Le code source du noyau Linux est hébergé sur Git, le système de gestion de versions que Linus Torvalds a créé en 2005 pour le projet kernel. Chaque nouvelle version stable reçoit les correctifs de bugs et les patchs de sécurité rétro-portés depuis la branche de développement. Quand une branche passe en fin de vie, ce travail de rétro-portage s'arrête définitivement.

Ce choix n'est pas inhabituel : la plupart des noyaux stables non-LTS sont remplacés quelques semaines après la sortie du suivant. Pour un administrateur de serveur, cela signifie qu'il faut suivre les sorties de noyaux et ne pas rester indéfiniment sur une version stable non-LTS.

Ce que vous risquez avec un noyau en fin de vie

Un noyau marqué EOL ne reçoit plus aucune mise à jour. Les conséquences pour un serveur en production :

• Failles de sécurité non corrigées : toute vulnérabilité découverte dans le noyau 7.2 après le 1er novembre 2026 ne sera pas patchée. Les failles noyau permettent des escalades de privilèges, des évasions de conteneurs Docker et des accès root non autorisés.
• Incompatibilités logicielles : les nouvelles versions de distributions, de Docker, de Proxmox VE ou de pilotes GPU finissent par exiger un noyau minimum supérieur au 7.2. Vos paquets Nginx, Apache, MySQL, PostgreSQL et vos scripts Python ou Bash risquent de rencontrer des problèmes si le kernel sous-jacent n'est plus à jour.
• Absence de correctifs de stabilité : les bugs de régression découverts après l'EOL (fuites de mémoire RAM, corruption de système de fichiers, paniques kernel) ne seront pas corrigés. Un restart du serveur peut temporairement masquer le problème, mais sans patch la situation finira par se reproduire.
• Non-conformité sécurité : un noyau obsolète peut invalider les audits de sécurité de votre infrastructure. Le firewall noyau (netfilter/nftables) ne recevra plus de correctifs, ce qui fragilise toute la chaîne de sécurité réseau. Votre configuration nftables n'est efficace que si le noyau qui l'exécute est maintenu.

Si vous sécurisez l'accès SSH de votre VPS et automatisez les mises à jour de sécurité, le noyau reste le dernier maillon : un kernel obsolète annule ces protections.

Migrer vers le noyau 7.3.y

La branche stable actuelle est le noyau 7.3.1, disponible depuis le 30 octobre 2026. C'est la cible de migration naturelle pour les serveurs qui tournaient sous 7.2. Pour découvrir les nouveautés de cette nouvelle version, consultez notre article Kernel Linux 7.3 : ce qui change pour votre VPS et serveur dédié. Faites un backup complet avant toute opération.

Sur Ubuntu ou Debian (VPS et serveurs dédiés)

Les distributions stables n'installent pas le dernier noyau mainline automatiquement. Le processus dépend de votre configuration :

• Ubuntu LTS avec HWE : le paquet linux-generic-hwe intégrera le noyau 7.3 après validation par Canonical. En attendant, les correctifs de sécurité sont rétroportés sur le noyau de votre version LTS. Vérifiez votre noyau HWE avec apt list --installed 2>/dev/null | grep linux-image.
• Debian stable : le noyau de Debian stable ne change pas de version majeure en cours de cycle. Les correctifs de sécurité sont rétroportés par l'équipe sécurité Debian. Pour installer un noyau plus récent, activez les backports : sudo apt install -t bookworm-backports linux-image-amd64.
• Distributions rolling-release (Arch, Fedora) : la mise à jour vers 7.3 arrive directement via le gestionnaire de paquets. Un simple sudo dnf upgrade ou sudo pacman -Syu suffit.

Après installation du nouveau paquet noyau, redémarrez le serveur avec sudo reboot et vérifiez avec uname -r que la version active est bien en 7.3.x. Pensez à sauvegarder votre VPS avant tout changement de noyau.

Sur CentOS, AlmaLinux ou Rocky Linux

Les distributions de la famille RHEL gèrent les paquets noyau avec dnf (ou yum sur les anciennes versions de CentOS). Mettez à jour le package kernel depuis le terminal :

sudo dnf update kernel

La commande télécharge et installe le dernier paquet kernel disponible dans les dépôts. Après le restart du serveur, vérifiez la nouvelle version :

sudo reboot
# après redémarrage :
uname -r

Sur CentOS Stream ou Fedora, le noyau 7.3 sera disponible directement dans les dépôts. Sur AlmaLinux et Rocky Linux (clones RHEL), le noyau suit le cycle de Red Hat : les correctifs sont rétroportés sur le noyau de base de la distribution, même si le numéro de version ne change pas. Consultez les notes de version de votre distribution pour connaître le noyau upstream correspondant à votre paquet kernel.

Sur Proxmox VE (serveur dédié)

Proxmox VE distribue ses propres paquets noyau, optimisés pour la virtualisation KVM et les conteneurs LXC. La mise à jour se fait depuis le terminal :

sudo apt update && sudo apt full-upgrade

Proxmox intègre les noyaux stables avec un décalage de quelques semaines. Surveillez le changelog des paquets proxmox-ve et pve-kernel pour savoir quand le 7.3 sera disponible. Après la mise à jour, un restart de l'hyperviseur est nécessaire : toutes les machines virtuelles hébergées seront temporairement arrêtées.

Configurer GRUB après la migration

GRUB (GRand Unified Bootloader) est le chargeur de démarrage qui sélectionne le noyau à lancer au boot du serveur. Après l'installation d'un nouveau noyau, GRUB est normalement mis à jour automatiquement par les scripts post-installation du paquet. Vérifiez que le noyau 7.3 est bien l'entrée par défaut dans le fichier de conf GRUB :

grep GRUB_DEFAULT /etc/default/grub

Si la valeur est 0, GRUB démarre sur le premier noyau de la liste (le plus récent). Si vous avez configuré une valeur fixe, mettez à jour le fichier de configuration :

sudo nano /etc/default/grub
# Vérifiez : GRUB_DEFAULT=0
sudo update-grub

Sur CentOS ou AlmaLinux, la commande équivalente pour régénérer la config GRUB est :

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Si le serveur ne démarre pas correctement après la migration, accédez à la console de récupération (KVM/IPMI sur un serveur dédié, console VNC sur un VPS) et sélectionnez l'ancien noyau dans le menu GRUB au boot pour restaurer l'accès. Ne supprimez pas l'ancien noyau 7.2 tant que la stabilité du nouveau n'est pas confirmée.

Compiler le noyau depuis les sources (usage avancé)

La plupart des administrateurs n'ont pas besoin de compiler le noyau : les paquets fournis par la distribution suffisent. Pour les cas particuliers (modules DKMS incompatibles, patches spécifiques, configuration matérielle non couverte), le noyau 7.3 peut être compilé depuis les sources hébergées sur le dépôt Git officiel :

sudo apt install build-essential libncurses-dev flex bison libssl-dev libelf-dev
git clone --depth 1 --branch v7.3.1 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux
cp /boot/config-$(uname -r) .config
make olddefconfig
make -j$(nproc)
sudo make modules_install
sudo make install
sudo update-grub

Le temps de compilation varie de 10 à 45 minutes selon le nombre de cores du processeur. Le fichier .config copié depuis /boot/ reprend la configuration de votre noyau actuel. La commande make olddefconfig applique les valeurs par défaut pour les nouvelles options du noyau 7.3. Cette méthode est réservée aux utilisateurs avancés : un script de compilation mal configuré peut produire un noyau qui ne boot pas.

Noyau 7.4 : faut-il attendre ?

Le noyau 7.4-rc1 (release candidate) est sorti le 1er novembre 2026. La version stable finale est attendue courant décembre 2026. Si votre serveur est actuellement sur un noyau LTS (6.6, 6.12, 6.18) et que tout fonctionne, il n'y a pas d'urgence à migrer : ces branches LTS continueront à recevoir des correctifs de sécurité pendant plusieurs années.

En revanche, si vous êtes sur un noyau 7.2.x, n'attendez pas le 7.4 : migrez vers 7.3.y dès maintenant pour restaurer la couverture de sécurité de votre serveur. Une fois le 7.4 stabilisé, vous pourrez migrer à nouveau si les nouveautés vous intéressent.

Branches noyau Linux actuellement maintenues

Le tableau ci-dessous récapitule l'état des branches au 3 novembre 2026, tel qu'affiché sur kernel.org :

Checklist pour l'administrateur

1. Vérifiez votre version de noyau avec uname -r depuis un terminal.
2. Si le résultat commence par 7.2, planifiez la migration vers 7.3.y.
3. Faites un backup complet de votre serveur avant de changer de noyau (guide rsync).
4. Installez le nouveau paquet noyau via votre gestionnaire de paquets (sudo apt, sudo dnf).
5. Vérifiez la configuration de GRUB : le nouveau noyau doit être l'entrée de boot par défaut.
6. Redémarrez le serveur avec sudo reboot et vérifiez que le noyau actif est bien en 7.3.x.
7. Contrôlez que vos services critiques fonctionnent après le restart : Nginx ou Apache (web), MySQL ou PostgreSQL (base de données), serveur DNS, Docker, services FTP et vos scripts d'automatisation.
8. Supprimez les anciens noyaux 7.2 pour libérer de l'espace disque : sudo apt autoremove --purge.
9. Surveillez les ressources (CPU, RAM, disque) de votre serveur pendant quelques jours après la migration pour détecter d'éventuelles régressions.

Questions fréquentes