Comment VsockDrop accède aux droits root sans hyperviseur ni privilèges

En bref

Aller directement à la version longue ↓

Une faille du noyau Linux, notée 5,5, fait désormais l'objet d'un exploit public permettant à un utilisateur local sans privilèges d'accéder au compte root. C'est l'aspect de la faille VsockDrop (CVE-2026-53365) qui mérite une attention particulière cette semaine.

Description : VsockDrop est un exploit d’élévation de privilèges locale (LPE) lié à la vulnérabilité CVE-2026-53365, une faille dans le chemin d’envoi « zerocopy » de virtio vsock du noyau Linux. Lorsqu’un message MSG_ZEROCOPY volumineux envoie des fragments répartis sur plusieurs tampons de socket, seul le dernier tampon contient l’objet d’achèvement recherché par le chemin de libération. Tous les tampons situés avant celui-ci contiennent des pages utilisateur épinglées, et le noyau supprime alors une référence de page qu’il n’a jamais prise.

Impact potentiel : obtention des droits root à partir d’un compte ordinaire sans privilèges. L’exploit réduit à zéro le compteur de références d’une page, récupère cette page toujours épinglée en tant que cache de page pour /usr/bin/su, réécrit le chemin d’accès à l’interpréteur qui y est stocké, puis exécute su. Il n’y a ni fuite d’informations ni exécution de code du noyau à aucun moment de la chaîne d’exploitation, ce qui explique en grande partie pourquoi cette technique fonctionne de manière aussi cohérente.

Gravité : Red Hat et le NVD publient tous deux un score CVSS de base de 5,5 pour la vulnérabilité CVE-2026-53365, avec un impact élevé sur la disponibilité et aucun impact sur la confidentialité ou l’intégrité ; Red Hat attribue à cette vulnérabilité le niveau de gravité « Modéré ». L'auteur de l'exploit plaide en faveur d'un score de 7,8. Le vecteur décrit la défaillance de comptabilisation des ressources mentionnée dans le message de commit en amont. Il ne tient pas compte de l'interaction io_uring qui transforme ce même objet de finalisation manquant en une page libérée alors qu'elle est encore en cours d'utilisation. Quelle que soit la note finale attribuée, l'exploit rendu public met en évidence des conséquences en matière de confidentialité et d'intégrité que le vecteur de 5,5 actuellement publié ne prend pas en compte.

Qui est concerné : Ubuntu mérite une attention immédiate. Les noyaux Linux à partir de la version 6.7 qui n'ont pas appliqué le correctif sont affectés, et l'exploitabilité de la faille dépend de la capacité d'un processus sans privilèges à utiliser des tampons enregistrés via io_uring en combinaison avec un transport vsock autorisant le zerocopy. Ces deux éléments sont disponibles par défaut sur Ubuntu 24.04 et sur Ubuntu 22.04 exécutant le noyau 6.8 HWE. Enterprise Linux 9 et 10, notamment RHEL, AlmaLinux, Rocky et CloudLinux, contiennent le même code vulnérable, mais sont livrés avec le paramètre `kernel.io_uring_disabled` défini sur 2, ce qui bloque la chaîne d'exploitation démontrée.

Ce qui a été vérifié : le 18 août 2026, TuxCare a réussi à obtenir un shell root sur Ubuntu 24.04 à partir d’un compte sans privilèges dès la première tentative, sans aucune modification de configuration. Sur AlmaLinux 10.2, le même exploit s'est arrêté lors de l'initialisation d'io_uring dans la version d'origine, puis a permis d'obtenir les droits root une fois qu'io_uring a été explicitement réactivé. Une tentative sur AlmaLinux 9.8 avec io_uring réactivé n'a pas permis d'obtenir les droits root, ce qui n'équivaut pas à un résultat négatif formel.

Que faire maintenant : identifiez le noyau en cours d'exécution et la politique io_uring, puis vérifiez si vsock est chargé.

uname -r
sysctl kernel.io_uring_disabled
lsmod | grep -E 'vsock|vmw_vsock'

Une valeur de 2 signifie que io_uring est désactivé à l'échelle du système, y compris pour l'utilisateur root, ce qui bloque la faille d'exploitation connue affectant root sans pour autant supprimer le code vulnérable. Une valeur de 0 signifie que io_uring est disponible ; il s'agit de la valeur par défaut en amont et de celle fournie par Ubuntu. La sortie de la troisième commande confirme qu'un module lié à vsock est chargé. L'exploit public peut utiliser vsock_loopback et VMADDR_CID_LOCAL ; une machine virtuelle n'est donc pas nécessaire.

Appliquez un noyau fourni par le fabricant lorsqu'il en existe un. Debian 13 en propose un. Canonical n'en a pas fourni pour les deux versions d'Ubuntu les plus importantes. Lorsqu'un redémarrage ne peut pas avoir lieu immédiatement, KernelCare est la solution habituelle pour obtenir un noyau fonctionnel ne présentant plus le bogue ; aucun correctif ne nécessitant pas de redémarrage n'ayant encore été publié pour cette vulnérabilité (CVE), les mesures d'atténuation ci-dessous constituent la solution provisoire pour ces systèmes.

Ce qui est intéressant dans l'affaire VsockDrop, ce n'est pas tant l'existence d'une nouvelle vulnérabilité CVE dans le noyau Linux, mais plutôt l'écart entre ce que décrit la fiche CVE et ce que fait réellement l'exploit rendu public.

La vulnérabilité CVE-2026-53365 a été publiée le 13 juillet 2026, deux mois après la mise en place du correctif en amont, le 14 mai. La description officielle fait état d'un suivi de l'achèvement du « zerocopy » et de pages épinglées qui ne sont jamais libérées ; tant Red Hat que le NVD attribuent à cette vulnérabilité une note de 5,5, avec un impact limité à la disponibilité.

C'est alors que la publication de cette faille a bouleversé la donne. Elle a démontré que cette même faille de gestion des références, combinée à des tampons enregistrés avec io_uring, permettait de libérer une page encore « épinglée », de la récupérer dans le cadre d'un binaire setuid et de transformer un utilisateur local ordinaire en root.

Une faille, deux conséquences. Le CVE n'a pris en compte que la plus bénigne. Si une note de 5,5 attribuée dans un rapport sur les vulnérabilités est la raison pour laquelle cette faille a été retirée d'une liste de correctifs, elle doit y être réintégrée.

En quoi consiste exactement la vulnérabilité CVE-2026-53365, également connue sous le nom de « VsockDrop » ?

VsockDrop est un exploit permettant l'élévation de privilèges locaux sans privilèges, lié à la vulnérabilité CVE-2026-53365 du noyau Linux, publié en août 2026 par Maher Azzouzi, qui est crédité comme auteur du rapport ayant conduit au correctif en amont. Ce nom désigne l'exploit et le document explicatif qui l'accompagne, et non une vulnérabilité distincte.

Le code vulnérable se trouve dans le chemin d'envoi « zerocopy » de virtio vsock. AF_VSOCK est généralement associé à la communication entre un invité et son hyperviseur ; on pourrait donc naturellement supposer qu’il s’agit d’un problème de virtualisation. Ce n’est pas le cas. Linux expose un identifiant de contexte vsock local via le transport vsock_loopback, VMADDR_CID_LOCAL, qui correspond au CID 1, et la preuve de concept utilise ce point de terminaison pour communiquer avec le même système. Aucun hyperviseur, aucun invité, aucun espace de noms utilisateur et aucun contrôle de capacité ne s'interpose entre un compte ordinaire et le code vulnérable.

La condition préalable n'est donc pas de contrôler un hyperviseur. Il s'agit plutôt de la possibilité d'exécuter un binaire en tant qu'utilisateur local normal sur un noyau vulnérable où les fonctionnalités requises sont disponibles. Sur les hébergements mutualisés, les systèmes de compilation multi-locataires, les runners d'intégration continue et les hôtes relais, cela correspond à la plupart des comptes présents sur la machine.

Le deuxième élément clé est io_uring. L'exploit utilise des tampons enregistrés associés à un transfert « zerocopy », et c'est précisément cette interaction qui transforme un bug lié à la comptabilisation des pages en un débordement de référence, puis permet d'obtenir les privilèges root.

Le moment choisi a également son importance. Le correctif est public depuis le 14 mai 2026 ; il a été rédigé par Stefano Garzarella, de Red Hat, et l’exploit est apparu environ trois mois plus tard. Personne n’a été pris au dépourvu, ce qui signifie également que tous les noyaux non mis à jour ont été exposés à une faille pour laquelle un correctif avait été publié depuis un trimestre entier.

Fonctionnement de l'exploit root « VsockDrop »

Une opération d’envoi MSG_ZEROCOPY ne copie pas la charge utile. Le noyau verrouille les pages utilisateur, effectue la transmission à partir de celles-ci, puis informe l’espace utilisateur via la file d’attente d’erreurs lorsque ces pages peuvent être réutilisées en toute sécurité. L’objet qui gère tout cela est l’ubuf_info, généralement appelé « uarg ».

Avec le mode « zerocopy », le chemin d'envoi vsock limite chaque tampon de socket à 64 KiB ; par conséquent, tout ce qui dépasse cette taille est fragmenté. Avant la correction, l'argument « uarg » n'était associé qu'au dernier tampon de la boucle. Les tampons précédents contenaient toujours des pages fixées, sans présenter l'état d'achèvement que le noyau s'attendait à y trouver.

En soi, cela engendre le problème de comptabilisation des ressources décrit par le CVE. L'espace utilisateur n'est jamais informé que ces pages sont libres, et si la boucle d'envoi s'interrompt prématurément, l'uarg n'est tout simplement jamais alloué.

Avec les tampons enregistrés via io_uring, les conséquences sont différentes. Ces pages sont déjà verrouillées à long terme, et la pile réseau marque les fragments comme des références gérées, ce qui signifie que le processus de libération ne doit pas les toucher. Le mécanisme de protection qui assure cela s'inscrit dans le cadre d'une vérification visant à déterminer si le tampon est associé à un uarg. L'absence d'uarg entraîne l'échec de la vérification ; le mécanisme de protection n'est alors jamais sollicité, et la boucle unref appelle la fonction put_page() sur les fragments qui n'ont jamais fait l'objet d'une référence. Il en résulte une diminution erronée du compteur de références de page à chaque envoi.

L'envoi de la même charge utile via une fonction `iovec` classique ne produit aucun résultat. Dans ce cas, `io_uring` prend les références appropriées, la comptabilité s'équilibre, et seule la fuite de mémoire subsiste. Sans `io_uring`, pas de sous-débordement.

À partir de là, le calcul est impitoyable. Le biais de pin est de 1 024, une constante ABI fixe ; ainsi, un nombre connu d’envois épuise un nombre connu de comptes de référence sur tout noyau concerné. Enregistrez un tampon, désenregistrez-le, envoyez jusqu’à ce que le compte atteigne zéro, et le noyau libère une page sur laquelle io_uring maintient encore un pin. En lisant une page « froide » de /usr/bin/su, l’allocateur renvoie immédiatement cette même page physique dans le cache de pages, car la liste des pages libres fonctionne selon le principe « dernier entré, premier sorti ». Le tampon toujours enregistré fait désormais office d’alias de ce cache de pages ; une écriture fixe réécrit le chemin d’accès à l’interpréteur ELF, et l’exécution de su amène le noyau à charger un interpréteur fourni par l’attaquant, avec des privilèges root déjà appliqués.

Il n'y a pas d'exécution de code du noyau dans cette chaîne. Il s'agit d'un chemin vers les droits root exclusivement basé sur les données, et si ce schéma vous semble familier, c'est normal. La faille « Copy Fail » (CVE-2026-31431) avait exploité un principe similaire plus tôt en 2026, en corrompant le cache de pages d'un binaire setuid pour obtenir les droits root sans modifier le fichier sous-jacent. VsockDrop atteint un objectif similaire en exploitant une faille du noyau très différente.

Il y a un détail important à retenir pour quiconque souhaite tester cela. Le drain de référence est déterministe. La phase de récupération des pages est probabiliste, et une tentative infructueuse ne peut pas être réitérée lors du même démarrage. L'exploit est donc fiable sans pour autant être « one-shot », et un seul échec ne prouve pas que le noyau n'est pas affecté.

A-t-on confirmé que la vulnérabilité « VsockDrop » pouvait être exploitée ?

Oui, sur un noyau Ubuntu 24.04 concerné, sans aucune modification de configuration.

Le 18 août 2026, TuxCare a reproduit l'exploit rendu public sur Ubuntu 24.04, équipée d'un noyau Azure 6.17. L'exécution a débuté à partir d'un compte sans privilèges et a permis d'obtenir un shell root dès la première tentative, sans aucun réglage ni reconfiguration. Le seul effet secondaire a été l'apparition d'un message « BUG : Bad page state » dans le fichier dmesg. Cette image ne contient pas le correctif, et Canonical n'en a pas publié pour cette version.

AlmaLinux 10.2 s'est comporté de manière très différente. L'exploit s'est arrêté immédiatement avec l'erreur « io_uring init failed », ce qui s'explique par le fait que la valeur par défaut du paramètre `kernel.io_uring_disabled = 2` fait exactement ce qu'elle est censée faire. Ce n'est pas SELinux qui l'empêche de fonctionner, au cas où ce serait l'hypothèse qui circulerait dans la salle. Il n’y a eu aucun refus AVC, et l’exécution a tout de même échoué avec SELinux en mode permissif. Avec le paramètre sysctl réglé sur 0, la tentative suivante a permis d’obtenir les privilèges root, avec un dmesg propre et aucun oops.

« Atténué tel quel » ne signifie pas « corrigé ».

AlmaLinux 9.8 est le cas qui mérite une attention particulière. Une fois io_uring réactivé, l’exploit s’est exécuté de bout en bout avant d’échouer sans parvenir à obtenir les privilèges root. Il ne s’agit donc pas d’un résultat négatif sans équivoque. Toutes les conditions préalables au débordement par sous-débit sont présentes dans le noyau 5.14 fourni, l’opcode « zerocopy send » dont l’exploit a besoin a été rétroporté dans cette branche du noyau, et Red Hat continue de considérer RHEL 9 comme vulnérable. La signature de l’échec correspondait à un échec connu sur un hôte qui avait déjà été rooté. Enterprise Linux 9 doit être considéré comme vulnérable dans le code jusqu’à ce qu’un test approprié prouve le contraire.

Une tentative ratée laisse également des traces, qui s'avèrent plus utiles qu'il n'y paraît. L'exploit ne nettoie ses traces qu'en cas de réussite ; ainsi, un échec laisse derrière lui les fichiers /tmp/loader et /var/tmp/.s, ce dernier étant défini avec le droit setuid root. Il s'agit là d'un vecteur d'élévation de privilèges locaux laissé sur l'hôte par une tentative qui n'a même pas abouti, et personne ne va chercher quoi que ce soit dans /var/tmp. Supprimez-le manuellement.

Une exécution réussie bloque la commande « su » jusqu’au redémarrage, avec le message d’erreur : « cannot execute : required file not found ». Vider les caches ne résout pas le problème, car la page corrompue conserve toujours une référence ; seul un redémarrage permet donc de rétablir la situation. Il s’agit là d’un signal de détection peu coûteux et d’une interruption visible par l’utilisateur à part entière. La corruption persiste dans le cache de pages, et sur AlmaLinux, la commande « rpm -V util-linux-core » n’a révélé aucune anomalie par la suite, ce qui indique que le binaire sur le disque n’avait pas été altéré. Sur un système de fichiers de type « copy-on-write », cela pourrait ne pas tenir la route, comme le signale l’auteur de l’exploit lui-même.

Ubuntu 24.04 est-il vulnérable à la faille VsockDrop ?

Oui. Les versions concernées du noyau d'Ubuntu 24.04 sont vulnérables, et l'exploit public permettant d'obtenir les droits root a été reproduit sur Ubuntu 24.04 sans aucune modification de configuration.

Canonical répertorie actuellement la vulnérabilité CVE-2026-53365 comme affectant l’ensemble des paquets du noyau Noble, qui couvrent les versions 6.8 GA et 6.17 HWE, ainsi que les variantes AWS, Azure, GCP et GKE. Ubuntu 22.04, qui utilise le noyau 6.8 HWE, est également répertorié comme vulnérable, et c’est cette version qui compte la plus grande base d’utilisateurs parmi les deux.

L'impact d'Ubuntu est plus important que ne le laisse supposer la liste des paquets concernés, car sa configuration par défaut de `io_uring` laisse la vulnérabilité nécessaire à l'exploitation exposée. Canonical attribue également à ce CVE un niveau de gravité « moyen », ce qui explique pourquoi aucune alerte de sécurité n'a été émise pour ces lignes.

Les nouveaux noyaux basés sur la version 7.0 font l'objet d'un développement distinct. Canonical indique actuellement qu'Ubuntu 26.04 et la branche Ubuntu 24.04 HWE 7.0 sont toutes deux vulnérables et que des correctifs sont en cours d'élaboration ; veillez donc à vérifier l'état exact des paquets avant de considérer que l'une ou l'autre a été corrigée.

Quels sont les systèmes Linux concernés ?

Seule la situation en amont est simple. Les modifications apportées à vsock MSG_ZEROCOPY, à l’origine de ce comportement, ont été intégrées dans Linux 6.7, et les correctifs stables se trouvent dans les versions 6.12.97, 6.18.34, 7.0.11 et 7.1. Les noyaux des distributions doivent être évalués au cas par cas, en fonction des avis de sécurité et des paquets, car les éditeurs effectuent constamment des rétroportages de fonctionnalités. RHEL 9 indique un noyau basé sur la version 5.14, numériquement antérieur à la version 6.7, et Red Hat signale toujours que RHEL 9 et RHEL 10 sont affectés sans qu'aucun correctif n'ait été fourni, car la fonctionnalité a été rétroportée dans cette branche de noyau.

Les backports intègrent à la fois les fonctionnalités vulnérables et les correctifs dans des numéros de version qui ne correspondent pas à ceux de l'amont ; considérez donc la commande « uname -r » comme un identifiant à vérifier, et non comme un verdict définitif.

Ce qui protège Enterprise Linux 9 et 10, c'est cette valeur par défaut plutôt qu'un correctif ; elle est intégrée au noyau plutôt que fournie sous forme de fichier sysctl. Ainsi, tout système démarrant avec ce noyau en hérite, à moins que l'espace utilisateur ne la modifie par la suite. Les charges de travail liées aux bases de données, aux proxys et aux conteneurs la modifient délibérément, ce qui rend la vulnérabilité sur ces hôtes bien réelle et non plus hypothétique.

Comment atténuer les effets de VsockDrop

La chaîne présentée nécessite des tampons enregistrés via io_uring et un transport vsock prenant en charge le « zerocopy ». La suppression de l'une ou l'autre de ces conditions préalables entraîne une défaillance du système, ce qui représente tout de même une situation plus favorable que celle dans laquelle se retrouvent généralement les utilisateurs face à la plupart des bogues du noyau. Aucune de ces deux mesures ne peut toutefois se substituer à une correction au niveau du noyau.

1. Conservez la valeur « io_uring » sur « denied ». Sous Enterprise Linux 9 et 10, la valeur 2 correspond déjà à l'état par défaut ; il s'agit donc davantage d'une étape de vérification que d'une modification. Évitez de modifier ce paramètre, sauf si une charge de travail nécessite réellement l'utilisation de « io_uring ».

Ubuntu représente le cas inverse. La désactivation d'io_uring dans ce cas supprime des fonctionnalités dont les applications en cours d'exécution peuvent dépendre, notamment les bases de données, les proxys et les logiciels de stockage à haut débit ; il convient donc de considérer cette mesure comme un véritable changement opérationnel ayant un impact réel. C'est également la seule option d'exécution dont disposent ces systèmes jusqu'à ce qu'un correctif soit disponible. Lorsqu’un service spécifique a besoin d’io_uring, une valeur de 1 combinée à kernel.io_uring_group n’autorise son utilisation que pour les membres de ce groupe, et toute valeur autre que 2 ne doit pas être considérée comme équivalente à une désactivation totale.

2. Supprimez le transport vsock là où il n'est pas nécessaire. Sur un serveur physique ne comportant aucun consommateur vsock, l'ajout du module à la liste noire se déroule généralement sans incident.

lsmod | grep -E 'vsock|vmw_vsock'

Ne l'appliquez pas aveuglément à une machine qui est elle-même un invité. L'agent invité QEMU et VMware Tools utilisent tous deux le protocole vsock, tout comme la virtualisation imbriquée et tout ce qui s'apparente à Firecracker. Les modules déjà chargés nécessitent l'utilisation de la commande `rmmod` ou un redémarrage pour que l'ajout à la liste noire ait un effet ; assurez-vous donc que le module a bien disparu après cette opération.

Aucune de ces mesures de contrôle n'a été testée face à cette faille spécifique ; il convient donc de les considérer comme des mesures préalables plutôt que comme une neutralisation avérée.

La solution au problème VsockDrop

La correction en amont correspond au commit ae38d9179190, intitulé « vsock/virtio : correction de la finalisation du zerocopy pour les envois multi-SKB », et elle s'aligne sur le fonctionnement actuel du protocole TCP.

Au lieu de créer l'uarg en cours de route dans la boucle d'envoi et de l'associer au dernier tampon rencontré, la correction l'alloue dès le départ, l'associe à chaque tampon à l'aide d'une référence unique par tampon, puis rééquilibre la référence initiale par la suite. Chaque opération terminée décrémente le compteur, la notification n'est déclenchée qu'une fois le dernier tampon libéré, et un envoi qui échoue sans avoir transmis quoi que ce soit interrompt l'uarg de manière propre.

Cela résout les deux problèmes d'un seul coup. Chaque tampon contient désormais un uarg ; ainsi, le mécanisme de protection des fragments gérés dans la branche de libération est consulté comme prévu depuis le début, et les pertes de références isolées ne se produisent plus. Le travail de rétroportage dépend du degré de divergence entre le noyau de chaque fournisseur et la branche principale.

Le correctif est inclus dans les versions stables en amont 6.12.97, 6.18.34, 7.0.11 et 7.1. Les noyaux propriétaires peuvent intégrer ce même correctif sous des numéros de version totalement différents.

État du correctif ne nécessitant pas de redémarrage pour CVE-2026-53365

Au 18 août 2026, l'équipe KernelCare travaille sur des correctifs « live » ne nécessitant pas de redémarrage pour la plupart des distributions concernées. Les premiers correctifs devraient être déployés dans les 48 heures.

Lorsque les correctifs sont disponibles, ils sont déployés lors de la prochaine exécution planifiée ou à la demande.

kcarectl --update

Vérifiez ensuite ce que contient réellement le noyau en cours d'exécution.

kcarectl --patch-info | grep 'CVE-2026-53365'

Si cette vérification ne donne aucun résultat, ne considérez pas cette absence comme une protection ou une faille. Vérifiez le numéro exact du noyau auprès du support technique avant de supprimer une mesure d'atténuation temporaire, et non après. L'horodatage de la compilation d'un correctif est un indicateur secondaire moins fiable et ne doit pas être considéré comme une preuve concernant un CVE spécifique.

Découvrez comment KernelCare corrige les failles critiques du noyau sans redémarrage → 

Questions fréquentes sur VsockDrop

De quoi un attaquant a-t-il besoin pour exploiter la vulnérabilité CVE-2026-53365 ? La possibilité d'exécuter un binaire en tant qu'utilisateur local sans privilèges sur un noyau vulnérable, avec io_uring disponible et un transport vsock chargeable. Pas besoin d'hyperviseur, ni de machine invitée, ni d'espace de noms utilisateur, ni de matériel spécifique.

VsockDrop nécessite-t-il une machine virtuelle ? Non, et c'est là que la plupart des résumés se trompent. Le protocole de transport vsock_loopback permet à un processus sans privilèges de communiquer avec lui-même via le CID local ; ainsi, un hôte « bare-metal » ne disposant d'aucune virtualisation reste une option envisageable.

RHEL 9 et RHEL 10 sont-elles concernées par la vulnérabilité VsockDrop ? Red Hat considère que ces deux versions sont concernées, y compris kernel-rt, et qu'aucun correctif n'a été fourni. L'exploit public ne fonctionne pas tel quel, car ces noyaux bloquent io_uring par défaut ; la vulnérabilité n'apparaît donc que lorsque ce paramètre par défaut a été modifié.

La vulnérabilité CVE-2026-53365 peut-elle être exploitée à distance ? Non. Elle nécessite un compte local. Cela concerne tout de même l'hébergement mutualisé, les systèmes de compilation multi-locataires, les environnements d'intégration continue (CI) et tout hôte sur lequel un utilisateur de l'application peut exécuter un binaire.

Comment savoir si quelqu'un a tenté cette opération ? Vérifiez la présence du répertoire /var/tmp/.s, qui est créé lors d'une tentative infructueuse sous la forme d'un binaire setuid root, ainsi que du fichier /tmp/loader. Un commande « su » défaillante signalant l'absence d'un fichier requis, associée au message « BUG : Bad page state » dans dmesg, indique que l'opération a réussi lors de ce démarrage.

Existe-t-il un correctif pour la vulnérabilité CVE-2026-53365 ? Les correctifs en amont sont disponibles dans les versions 6.12.97, 6.18.34, 7.0.11 et 7.1, et Debian a fourni des correctifs pour Trixie et pour le noyau Bookworm 6.12. Canonical n'en a pas fourni pour les versions d'Ubuntu concernées, et aucun correctif ne nécessitant pas de redémarrage n'a été publié pour ce CVE à la date de rédaction de cet article.

Chronologie de VsockDrop

Références

• Maher Azzouzi, démonstration de faisabilité et note technique sur VsockDrop, https://github.com/MaherAzzouzi/vsockdrop
• Correction en amont sous Linux ae38d9179190, « vsock/virtio : correction de l'achèvement du zerocopy pour les envois multi-SKB », https://git.kernel.org/linus/ae38d9179190a956e2a87a69ef1dd6f451b51c4d
• Commit 581512a6dc93, « vsock/virtio : prise en charge du drapeau MSG_ZEROCOPY », qui a introduit le code concerné dans Linux 6.7
• Commit 1cb36e252211, la correction relative au comptage des pages épinglées, dont l'examen a mis en évidence ce défaut
• Red Hat CVE-2026-53365, https://access.redhat.com/security/cve/cve-2026-53365
• NVD CVE-2026-53365, https://nvd.nist.gov/vuln/detail/CVE-2026-53365
• Ubuntu CVE-2026-53365, https://ubuntu.com/security/CVE-2026-53365
• Debian CVE-2026-53365, https://security-tracker.debian.org/tracker/CVE-2026-53365