Noyau Linux : GhostLock, Bad Epoll, Januscape, OVSwrap

Shared FAQ page chrome (breadcrumb, dates, read time, «Continuer la lecture», enquiry block, category labels): see INDEX-AND-CHROME.md. Translate once.

Body

Plusieurs failles graves du noyau Linux ont été divulguées au cours du mois de juillet 2026. Elles sont particulièrement importantes pour les serveurs d'hébergement, les environnements multi-utilisateurs, les plateformes de conteneurs et les hôtes de virtualisation KVM.

Les failles couvertes par cet avis sont :

• CVE-2026-43499 : GhostLock
• CVE-2026-46242 : Bad Epoll
• CVE-2026-53359 : Januscape
• CVE-2026-64531 : OVSwrap

Selon le système d'exploitation, la version du noyau et les modules activés, ces failles peuvent permettre à un processus sans privilèges d'obtenir un accès root, de s'échapper d'un conteneur, de s'échapper d'une machine virtuelle ou de faire planter l'hôte physique.

Bien qu'il s'agisse principalement de failles locales, elles restent très pertinentes pour les serveurs d'hébergement exposés à internet. Un attaquant qui compromet un site web, un plugin, une installation de CMS ou un compte client peut déjà disposer d'un accès local suffisant pour attaquer le noyau sous-jacent.

Vue d'ensemble des failles

Faille	Impact principal	Systèmes les plus concernés
GhostLock : CVE-2026-43499	Élévation locale de privilèges vers root et évasion de conteneur	Serveurs multi-tenant, multi-utilisateurs et de conteneurs
Bad Epoll : CVE-2026-46242	Élévation locale de privilèges vers root	Branches de noyau récentes d'Enterprise Linux et d'Ubuntu
Januscape : CVE-2026-53359	Évasion d'un invité KVM vers l'hôte et plantage de l'hôte	Hyperviseurs KVM et serveurs exposant /dev/kvm
OVSwrap : CVE-2026-64531	Élévation locale de privilèges vers root via Open vSwitch	Systèmes contenant un module noyau Open vSwitch concerné

GhostLock : CVE-2026-43499

GhostLock est une faille use-after-free dans le code des mutex temps réel et de l'héritage de priorité des futex du noyau Linux.

Un processus local sans privilèges peut exploiter la faille pour obtenir les privilèges root. La même faille peut aussi être utilisée depuis l'intérieur d'un conteneur pour s'en échapper et compromettre l'hôte.

Aucune capability Linux particulière n'est requise, et les détails d'exploitation sont publics.

Il n'existe pas de mesure d'atténuation praticable par configuration. Un noyau corrigé ou un livepatch vérifié est nécessaire.

AlmaLinux, Rocky Linux et systèmes compatibles RHEL

GhostLock touche les branches de noyau prises en charge d'AlmaLinux 8, 9 et 10.

Les noyaux AlmaLinux suivants incluent la correction :

Système d'exploitation	Noyau corrigé minimal
AlmaLinux 8	4.18.0-553.141.2.el8_10
AlmaLinux 9	5.14.0-687.24.1.el9_8
AlmaLinux 10	6.12.0-211.32.1.el10_2

Les administrateurs Rocky Linux et RHEL doivent installer le dernier noyau disponible dans les dépôts de leur propre éditeur, plutôt que des paquets d'une autre distribution.

CloudLinux

GhostLock touche les branches de noyau CloudLinux prises en charge.

Les administrateurs doivent installer le dernier noyau CloudLinux ou confirmer que KernelCare a appliqué un livepatch couvrant :

CVE-2026-43499

Vérifier la couverture KernelCare :

kcarectl --update
kcarectl --patch-info | grep CVE-2026-43499

Oracle Linux

Les systèmes Oracle Linux peuvent exécuter soit :

• Red Hat Compatible Kernel : RHCK
• Unbreakable Enterprise Kernel : UEK

Oracle a publié des mises à jour de sécurité pour les branches de noyau RHCK et UEK concernées.

Identifier le noyau Oracle Linux actif :

cat /etc/oracle-release
uname -r
rpm -q kernel kernel-core kernel-uek kernel-uek-core

Un noyau en cours d'exécution dont le nom contient uek est un Unbreakable Enterprise Kernel.

Installez le dernier noyau depuis le dépôt Oracle Linux approprié et redémarrez. Les versions RHCK et UEK ne doivent pas être comparées directement, car elles utilisent des noms de paquets et une numérotation différents.

Ubuntu

Canonical classe GhostLock comme une faille de gravité élevée.

Au 5 août 2026, l'état du noyau Ubuntu standard est le suivant :

Version d'Ubuntu	État
Ubuntu 26.04 LTS	Corrigé
Ubuntu 24.04 LTS	Corrigé
Ubuntu 22.04 LTS	Mise à jour en cours
Ubuntu 20.04 LTS	Mise à jour en cours

Ubuntu fournit plusieurs variantes de noyau, dont les noyaux generic, Hardware Enablement, cloud-optimized, low-latency, real-time et FIPS.

L'état peut différer d'une variante à l'autre. Les administrateurs doivent vérifier le paquet exact installé plutôt que de se fier au seul numéro de version d'Ubuntu.

uname -r
dpkg -S /boot/vmlinuz-$(uname -r)

Installez toutes les mises à jour disponibles et redémarrez :

apt update
apt full-upgrade -y
reboot

Là où Ubuntu Livepatch est activé, confirmez que ce CVE précis est couvert :

canonical-livepatch refresh
canonical-livepatch status --verbose

Bad Epoll : CVE-2026-46242

Bad Epoll est une faille de type race condition et use-after-free dans le sous-système de notification d'événements epoll du noyau Linux.

Un processus sans privilèges peut déclencher la condition vulnérable et la convertir en accès arbitraire à la mémoire du noyau et en exécution au niveau root.

Ce problème est particulièrement pertinent pour les serveurs multi-tenant, car epoll est un mécanisme de base de Linux utilisé par les serveurs web, les workers PHP, les bases de données et de nombreux autres services.

Il n'existe pas de mesure d'atténuation praticable à l'exécution, car epoll ne peut pas être désactivé sur un serveur Linux en fonctionnement. Un noyau corrigé ou un livepatch vérifié est nécessaire.

AlmaLinux

Bad Epoll touche :

• AlmaLinux 9
• AlmaLinux 10

AlmaLinux 8 n'est pas concerné.

La correction est incluse dans :

Système d'exploitation	Noyau corrigé minimal
AlmaLinux 9	5.14.0-687.23.1.el9_8
AlmaLinux 10	6.12.0-211.31.1.el10_2

Les noyaux plus récents corrigeant GhostLock incluent aussi la correction de Bad Epoll.

CloudLinux

Les plateformes CloudLinux concernées sont :

• CloudLinux 9
• CloudLinux 9 LTS
• CloudLinux 10

Les branches de noyau CloudLinux 7 et CloudLinux 8 ne sont pas concernées par cette faille précise.

Vérifier la couverture KernelCare :

kcarectl --patch-info | grep CVE-2026-46242

Oracle Linux

Oracle a publié des mises à jour Bad Epoll pour les branches de noyau RHCK ou UEK concernées d'Oracle Linux 9 et 10.

Installez toutes les mises à jour Oracle Linux en cours et confirmez que le serveur démarre sur le noyau RHCK ou UEK mis à jour.

Ubuntu

Canonical classe Bad Epoll en gravité élevée.

L'état du noyau Ubuntu standard au 5 août 2026 est le suivant :

Version d'Ubuntu	État
Ubuntu 26.04 LTS	Corrigé
Ubuntu 24.04 LTS	Mise à jour en cours
Ubuntu 22.04 LTS	Non concerné
Ubuntu 20.04 LTS	Non concerné

Les variantes de noyau Ubuntu spécialisées peuvent avoir un état différent.

Identifier le paquet de noyau exact :

uname -r
dpkg -S /boot/vmlinuz-$(uname -r)

Installez toutes les mises à jour Ubuntu actuellement disponibles :

apt update
apt full-upgrade -y

Redémarrez là où une mise à jour du noyau a été installée :

reboot

Januscape : CVE-2026-53359

Januscape est une faille dans le code de gestion mémoire KVM/x86 du noyau Linux.

Son chemin d'attaque le plus grave permet à une machine virtuelle malveillante de s'échapper de l'invité et d'exécuter des commandes en root sur l'hôte physique de virtualisation.

La faille peut aussi permettre à un invité malveillant de faire planter le noyau de l'hôte, ce qui affecte toutes les machines virtuelles du serveur.

Januscape touche la virtualisation x86 Intel et AMD. Les serveurs qui n'hébergent normalement pas de machines virtuelles peuvent rester exposés là où un processus sans privilèges peut accéder à /dev/kvm.

Vérifier l'exposition KVM

lsmod | grep '^kvm'
ls -l /dev/kvm 2>/dev/null

AlmaLinux, CloudLinux et systèmes compatibles RHEL

Januscape touche les branches de noyau avec KVM activé d'AlmaLinux, de CloudLinux et des autres systèmes compatibles RHEL.

Les noyaux AlmaLinux plus récents corrigeant GhostLock, listés plus haut, incluent aussi la correction de Januscape.

Les administrateurs doivent installer le dernier noyau de l'éditeur et redémarrer.

Oracle Linux

Oracle a publié des mises à jour Januscape pour les branches de noyau RHCK et UEK concernées.

La correction doit être appliquée sur l'hôte KVM physique. Mettre à jour uniquement les systèmes d'exploitation invités ne protège pas l'hyperviseur.

Oracle Linux Virtualization Manager et les autres hôtes KVM doivent être mis à jour via les dépôts Oracle Linux appropriés.

Ubuntu

Canonical indique que Januscape touche Ubuntu sur les systèmes x86 Intel et AMD où la virtualisation KVM imbriquée (nested) est activée.

Vérifier si la virtualisation imbriquée est active :

grep . /sys/module/kvm_{amd,intel}/parameters/nested 2>/dev/null

Une valeur 1 ou Y indique que la virtualisation imbriquée est activée.

Là où la virtualisation imbriquée n'est pas nécessaire, elle peut être désactivée temporairement :

echo 'options kvm_amd nested=0' \
> /etc/modprobe.d/disable-kvm-nesting.conf

echo 'options kvm_intel nested=0' \
>> /etc/modprobe.d/disable-kvm-nesting.conf

Redémarrez le serveur ou rechargez en toute sécurité le module KVM concerné.

Cette mesure ne remplace pas la mise à jour du noyau requise.

Atténuation temporaire pour les serveurs sans virtualisation

Sur un serveur qui n'utilise pas la virtualisation KVM, empêchez le chargement des modules propres au matériel :

printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' \
> /etc/modprobe.d/disable-kvm.conf

Ne déchargez pas et ne bloquez pas les modules KVM sur un serveur qui exécute actuellement des machines virtuelles.

OVSwrap : CVE-2026-64531

OVSwrap est une faille du noyau Linux dans le code de validation des actions d'Open vSwitch.

Un processus local sans privilèges peut exploiter le module noyau vulnérable pour obtenir un accès root.

Open vSwitch n'a pas besoin d'être configuré ni en cours d'exécution. Le module vulnérable peut être chargé automatiquement lorsqu'une requête spécialement conçue est émise.

Un exploit public est disponible.

Vérifier si Open vSwitch est disponible

find /lib/modules/$(uname -r) \
-type f -name 'openvswitch.ko*' 2>/dev/null

Vérifier s'il est actuellement chargé :

lsmod | grep '^openvswitch'

La faille se trouve dans le module noyau. Vérifier seulement si le paquet userspace d'Open vSwitch est installé ne suffit pas.

AlmaLinux, Rocky Linux, RHEL et CloudLinux

OVSwrap touche une partie des familles de noyau Enterprise Linux 9 et 10.

Les serveurs concernés doivent installer le dernier noyau de l'éditeur ou confirmer qu'un livepatch KernelCare applicable a été appliqué.

kcarectl --patch-info | grep CVE-2026-64531

Oracle Linux

Les administrateurs Oracle Linux doivent vérifier si le module Open vSwitch est disponible dans le noyau RHCK ou UEK actif.

Installez toutes les mises à jour de sécurité du noyau Oracle Linux en cours et appliquez l'atténuation temporaire du module là où Open vSwitch n'est pas nécessaire.

Ubuntu

Les serveurs Ubuntu doivent être considérés comme potentiellement exposés là où le noyau en cours d'exécution contient le module Open vSwitch et où le paquet installé n'a pas été confirmé comme corrigé.

Identifier le paquet du noyau en cours d'exécution :

uname -r
dpkg -S /boot/vmlinuz-$(uname -r)

Vérifier la présence du module :

find /lib/modules/$(uname -r) \
-type f -name 'openvswitch.ko*' 2>/dev/null

Installez toutes les mises à jour de sécurité Ubuntu actuellement disponibles.

Atténuation temporaire d'OVSwrap

Sur un serveur qui n'utilise pas Open vSwitch, empêchez le chargement du module :

echo 'install openvswitch /bin/false' \
> /etc/modprobe.d/ovswrap.conf

Si le module est déjà chargé et n'est pas utilisé :

modprobe -r openvswitch

Sur Ubuntu, régénérez le système de fichiers RAM initial :

update-initramfs -u

Sur les systèmes compatibles RHEL et Oracle Linux :

dracut -f

N'appliquez pas cette atténuation aux environnements de virtualisation, de réseau ou de conteneurs qui dépendent réellement d'Open vSwitch.

Mettre à jour AlmaLinux, CloudLinux, Rocky Linux et les systèmes compatibles RHEL

Mettez à jour et redémarrez. Vérifiez le noyau en cours d'exécution avec uname -r (et rpm -q kernel kernel-core kernel-uek sur Oracle Linux, dpkg -S /boot/vmlinuz-$(uname -r) sur Ubuntu) ; un livepatch ne compte que s'il liste le CVE.

Mettre à jour Oracle Linux

Installez toutes les mises à jour Oracle Linux disponibles :

dnf clean all
dnf update -y

Passez en revue les noyaux RHCK et UEK installés :

rpm -q kernel kernel-core kernel-uek kernel-uek-core

Vérifiez le noyau de démarrage par défaut :

grubby --default-kernel

Redémarrez et vérifiez :

reboot

uname -r

Mettre à jour Ubuntu

Identifiez la version d'Ubuntu et le paquet du noyau en cours d'exécution :

cat /etc/os-release
uname -r
dpkg -S /boot/vmlinuz-$(uname -r)

Installez toutes les mises à jour disponibles :

apt update
apt full-upgrade -y

Vérifiez si un redémarrage est requis :

test -f /var/run/reboot-required \
&& cat /var/run/reboot-required

Redémarrez et vérifiez :

reboot

uname -r

L'état de sécurité du noyau Ubuntu generic ne peut pas être transposé automatiquement aux variantes Hardware Enablement, cloud-optimized, low-latency, real-time ou FIPS.

Vérification après mise à jour

Après l'application des mises à jour, vérifiez le système d'exploitation et le noyau actif :

cat /etc/os-release
uname -r

Vérifiez si des modules KVM ou Open vSwitch restent chargés :

lsmod | grep -E '^(kvm|openvswitch)'

Sur les systèmes avec KernelCare :

kcarectl --patch-info \
| grep -E \
'CVE-2026-43499|CVE-2026-46242|CVE-2026-53359|CVE-2026-64531'

Sur les systèmes Ubuntu utilisant Livepatch :

canonical-livepatch status --verbose

Recommandations EuroVPS

EuroVPS recommande aux administrateurs de serveurs d'hébergement et de virtualisation Linux :

1. de vérifier la couverture KernelCare ou Ubuntu Livepatch individuellement pour chaque CVE ;
2. de désactiver KVM ou la virtualisation imbriquée là où ils ne sont pas nécessaires ;
3. de bloquer le module Open vSwitch là où il est présent mais inutile ;
4. d'examiner les sites web ou comptes utilisateur compromis, car la correction du noyau ne supprime pas une compromission existante.

Les panneaux de contrôle tels que cPanel et Plesk ne remplacent pas le noyau du système d'exploitation sous-jacent. Les mises à jour du noyau doivent toujours être installées via l'éditeur du système d'exploitation ou un fournisseur de livepatch approuvé.

Besoin d'aide ?

Si votre serveur est infogéré par EuroVPS, ouvrez un ticket : nous vérifions l'exposition, appliquons les mises à jour, coordonnons le redémarrage et examinons le serveur à la recherche de signes de compromission.