Des rapports sur le noyau Linux qui ont fuité font état de deux bogues dans ksmbd et d'une faille d'exploitation permettant d'accéder aux privilèges root qui contourne le correctif « Dirty Frag Fix »

En bref

Aller directement à la version longue ↓

Ce qui s'est passé : les 20 et 21 octobre 2026 (UTC), la Zero Day Initiative (ZDI) de Trend Micro a envoyé six rapports de vulnérabilité à l'équipe de sécurité du noyau et, par erreur, à des listes de diffusion publiques, notamment LKML et netdev. Cinq d'entre eux concernent des bogues du noyau et un concerne ConnMan, un gestionnaire de réseau en espace utilisateur. Aucun n'était accompagné d'un correctif, aucun n'a encore de numéro CVE, et trois comprenaient le code source complet d'une preuve de concept (PoC). Phoronix a couvert cette actualité le 22 octobre. Aller à cette section →

Celle qui compte :ZDI-CAN-33367 est une faille dans la fonction d'assistance réseau skb_zerocopy qui permet à un utilisateur local non privilégié d'écrire dans le cache de pages d'un fichier qu'il ne peut que lire. Il appartient à la même catégorie que « Dirty Pipe » et n'est qu'à un pas de l'accès root. TuxCare a reproduit cette faille en interne pour obtenir un shell root ; elle contourne le correctif apporté en mai pour « Dirty Frag » (CVE-2026-43284), et lorsque les rapports ont été rendus publics, aucun correctif n'avait encore été intégré en amont ni livré dans le noyau d'une distribution. Il s'agissait donc bel et bien d'une faille « zero-day ». Aller à cette section →

Qui est concerné : lors des tests menés par TuxCare, l’exploit a permis d’obtenir les privilèges root sur AlmaLinux 8, 9 et 10, CloudLinux 9 et 10, Debian 12 et 13, ainsi que sur Ubuntu 24.04 et 26.04, en contournant au passage les restrictions imposées par AppArmor d’Ubuntu. Les noyaux CentOS 6 et 7 ne sont pas vulnérables. CloudLinux 8, qui intègre tous les modules nécessaires à l'exploitation, et Ubuntu 22.04 n'ont pas encore été testés. Aller à cette section →

Qu'en est-il des vulnérabilités notées 9,0 ksmbd ? Dans les deux cas, le serveur SMB intégré au noyau doit être en cours d'exécution, et celui-ci reste désactivé à moins qu'un administrateur ne le configure délibérément. Les preuves de concept (PoC) rendues publiques mettent en évidence une fuite de mémoire dans le tas du noyau et des plantages, plutôt qu'une exécution de code, même si cela n'exclut pas des conséquences plus graves. Aller à cette section →

État des lieux : il n'y a toujours pas de CVE pour ZDI-CAN-33367. Le correctif en amont a été intégré à l'arborescence réseau du noyau, mais n'a pas encore atteint la branche principale. AlmaLinux 9 a livré un noyau corrigé, ce qui n'est pas encore le cas d'AlmaLinux 10. Le correctif sans redémarrage de KernelCare est disponible pour EL10 et EL9, celui pour EL8 est prêt à être publié, et les travaux sur Debian et Ubuntu sont en cours. Aucune exploitation en milieu réel n'a été signalée au 27 octobre. Aller à cette section →

Au programme aujourd'hui : Vérifiez si les espaces de noms des utilisateurs non privilégiés sont activés, et désactivez-les sur les hôtes qui n'en ont pas besoin. A 0 Cela signifie qu'aucun nouvel espace de noms utilisateur ne peut être créé, ce qui devrait empêcher le PoC public de fonctionner :

sysctl user.max_user_namespaces

Aller à cette section →

Les failles locales permettant l'escalade de privilèges ont tendance à être reléguées au rang de problèmes à traiter la semaine suivante. On se dit souvent qu'il faut d'abord qu'un attaquant dispose d'un shell, et que s'il en a déjà un, c'est qu'il y a des problèmes bien plus graves.

Cette logique ne tient pas sur les serveurs sur lesquels KernelCare s'exécute habituellement. Un serveur d’hébergement mutualisé comptant 300 comptes cPanel dispose, par nature, de 300 utilisateurs locaux, et chacun d’entre eux peut exécuter du code PHP ou une tâche cron. Un CI runner exécute tout ce que lui demande une pull request. Un nœud de connexion universitaire sert à fournir des shells. Dans tous ces cas, le terme « utilisateur local » désigne simplement un « client » ou une « tâche », et une écriture réussie dans le cache des pages peut conférer des droits root à n’importe lequel d’entre eux.

C'est là tout le problème avec ZDI-CAN-33367. Le rapport, l'analyse et le code source de la preuve de concept (PoC) ont été publiés sur les listes de diffusion publiques consacrées au noyau avant même qu'un correctif n'existe. Habituellement, le correctif est publié en premier, puis les détails suivent. Cette fois-ci, c'est l'inverse qui s'est produit.

Le guide du noyau lui-même concernant le signalement des failles de sécurité demande aux personnes qui les signalent de les envoyer en privé aux responsables des sous-systèmes et à l’équipe de sécurité du noyau, et non sur une liste publique, et de ne pas fournir de code permettant de reproduire la faille. De cette manière, un correctif peut être prêt avant que quiconque ne prenne connaissance des détails. ZDI fonctionne généralement de la même manière. Sa politique de divulgation accorde aux éditeurs 120 jours pour publier un correctif avant que les détails ne soient rendus publics, et sa liste des avis à venir indique une date limite fixée au 18 février 2027 pour les cinq rapports concernant le noyau.

Le rapport ConnMan a d'abord été publié sur la liste publique ConnMan, le 20 octobre à 00 h 17 UTC. La liste de ZDI indique quant à elle la date du 19 octobre, qui correspond à l'heure d'envoi selon l'heure américaine. Les cinq rapports concernant le noyau, dont le ZDI-CAN-33367, ont suivi dans la soirée du 21 octobre (UTC) ; ils ont été transmis à l’équipe de sécurité du noyau ainsi qu’aux listes LKML, netdev, linux-cifs, dri-devel et linux-nvme. Greg Kroah-Hartman et d’autres responsables ont répondu que ces rapports étaient désormais publics et qu’ils avaient été reçus sans correctifs. Trois des six rapports comprennent une description détaillée et le code source complet d’une preuve de concept (PoC). Deux rapports sur le noyau ne comportent rien de public hormis un titre, et le dernier ne concerne pas du tout un bug du noyau.

Curieusement, c’est justement la faille présentant le score de noyau le plus bas de la liste qui fait l’objet de la plus grande partie de cet article. Un score CVSS de base décrit la faille en elle-même. Il ne tient pas compte du fait qu’un code d’exploitation fonctionnel soit déjà public, ce qui est le cas pour ZDI-CAN-33367. Sur les machines où les conditions préalables à l’exploitation sont réunies, cela a plus d’importance qu’un ou deux points de score.

Aucun d'entre eux ne dispose encore d'un identifiant CVE. Cela peut sembler être une simple formalité administrative, mais de nombreux scanners et tableaux de bord de correctifs s'appuient exclusivement sur les identifiants CVE ; il est donc possible que ces rapports n'y apparaissent pas du tout pour l'instant. Prévoyez donc de compléter vos outils habituels par des vérifications manuelles et les mises à jour fournies par les éditeurs jusqu'à ce que ces identifiants soient disponibles.

skb_zerocopy() transfère les données par paquets entre les tampons de sockets en transmettant des références aux mêmes pages mémoire au lieu de copier les octets. C'est excellent pour le débit. C'est aussi le genre de raccourci qui revient sans cesse dans les bogues liés au cache de pages, où une référence à une page appartenant à un fichier se retrouve à un endroit où elle peut être écrite.

Dirty Pipe a réussi cet exploit via les canaux de communication en 2022. Copy Fail l’a fait via le socket cryptographique AF_ALG en avril 2026. En mai, Dirty Frag (CVE-2026-43284) l’a fait via ESP, la couche IPsec, qui déchiffrait les paquets sur place même lorsque leurs pages appartenaient à un fichier. ZDI-CAN-33367 est la suite de cette dernière faille.

Le correctif « Dirty Frag » a ajouté un mécanisme de protection. Lorsque des données de paquets proviennent de pages dont le noyau n'est pas le propriétaire exclusif, elles sont marquées d'un indicateur appelé SKBFL_SHARED_FRAG, et ESP vérifie cet indicateur et en fait une copie privée avant de procéder au déchiffrement. skb_zerocopy() transfère ces mêmes pages vers un nouveau tampon sans toutefois en conserver l'indicateur. La protection ne se déclenche jamais, ESP déchiffre les données sur place, et l'écriture aboutit dans le cache de pages d'un fichier que l'attaquant ne peut que lire. L'erreur sous-jacente remonte à la commande `commit` af2806f8f90a, qui a introduit skb_zerocopy() dans le noyau 3.14.

Cela a une conséquence fâcheuse. Les versions 8, 9 et 10 d’AlmaLinux intègrent toutes le correctif « Dirty Frag », comme l’a confirmé TuxCare dans les journaux de modifications du noyau AlmaLinux, et pourtant elles restent vulnérables. Un tableau de bord des correctifs indiquant que le CVE-2026-43284 est « résolu » ne vous apprend rien sur ce bogue.

Tout comme « Dirty Pipe », il s'agit ici d'une simple écriture dans le cache de page. Les processus qui lisent ou exécutent le fichier par la suite obtiennent la version modifiée par l'attaquant ; or, dans les cas de « Dirty Pipe » et de « Copy Fail », ces modifications n'ont jamais été répercutées sur le fichier au niveau du disque, ce qui a compliqué l'analyse forensic. Ciblez un binaire setuid ou /etc/passwd et l'accès root n'est plus qu'à un pas. L'exploit n'a besoin ni de privilèges particuliers ni d'une fuite KASLR pour y parvenir.

Le PoC publié comporte une liste d'éléments spécifiques. Il nécessite des espaces de noms d'utilisateurs sans privilèges, ce qui correspond à la méthode habituelle utilisée par un processus sans privilèges pour obtenir des droits d'administrateur réseau au sein de son propre bac à sable. Il s'appuie également sur des modules qui se chargent automatiquement à la demande : nfnetlink_queue, nft_queue, nlmon, cls_u32, act_pedit, act_mirred et esp4, ainsi que les modules cryptographiques sous-jacents à un chiffrement ESP non-AEAD. Le noyau 6.1 de Debian 12 nécessite un chemin légèrement différent pour intégrer des pages de fichiers dans un paquet, mais l'exploit fonctionne toujours dans ce cas. Cette liste décrit l'exploit public, et non toutes les voies d'accès possibles à la faille, mais c'est ce qui rend les mesures d'atténuation possibles, et ce point est abordé plus loin.

Eric Dumazet, responsable de Netdev, a répondu au rapport en indiquant qu’une autre source avait signalé le même bug, accompagné d’un correctif, une semaine plus tôt, et que la correction serait bientôt disponible. Le 22 octobre, ce correctif a été publié sur netdev. Il s’agit d’une modification d’une seule ligne qui permet à skb_zerocopy() de copier l’indicateur de page partagée, et il a été transmis en copie à l’équipe stable.  Il a depuis été intégré à l’arborescence « networking » sous le commit `79dc34beb1fd`, mais n’a pas encore atteint la branche principale. Quoi qu’il en soit, une correction dans l’arborescence d’un responsable ne préjuge en rien du moment où les noyaux corrigés seront disponibles sur vos machines. Une correction en amont doit encore être intégrée au noyau d’une distribution, puis devenir un paquet, avant d’être appliquée via un redémarrage ou un correctif sans redémarrage sur chaque serveur exposé, et le PoC se trouve déjà dans une archive publique.

TuxCare a recompilé le PoC public pour chacune des cibles ci-dessous et l'a exécuté. La mention « Root verified » signifie que l'exécution s'est terminée par l'obtention d'un shell avec l'uid 0.

Les deux anciennes versions sont sûres pour des raisons différentes. Le noyau 2.6.32 de CentOS 6 est antérieur à skb_zerocopy() entièrement, il n’y a donc rien à exploiter. Le noyau 3.10 de CentOS 7 dispose de cette fonctionnalité, mais son code ESP crée toujours une copie privée des paquets non linéaires avant de les déchiffrer. Le raccourci « in-place » a été intégré en amont dans la version 4.11, mais n’a jamais été intégré à EL7 ; de toute façon, les espaces de noms des utilisateurs non privilégiés y sont désactivés par défaut.

Ubuntu 22.04 et quelques branches de noyau distinctes n’ont toujours pas été testées, notamment les noyaux EL ELS, les noyaux AlmaLinux ESU et FIPS, Oracle UEK, les noyaux « cloud » et HWE, ainsi que le noyau CloudLinux 7. CloudLinux 8 n’a pas non plus été testé, mais son noyau intègre tous les modules requis par l’exploit public. Les noyaux corrigés de CloudLinux 7h et 8 (4.18.0-553.177.1.lve.1) sont en version bêta. Considérez-les tous comme potentiellement vulnérables jusqu’à ce qu’ils aient été vérifiés.

À partir d'Ubuntu 24.04, des restrictions AppArmor s'appliquent aux espaces de noms des utilisateurs sans privilèges, contrôlées par kernel.apparmor_restrict_unprivileged_userns. Cela n'a pas empêché cet exploit. Le PoC contourne cette protection en s'exécutant via le profil AppArmor d'un lanceur de conteneurs autorisé à créer des espaces de noms utilisateur. Ne considérez pas cela comme une mesure d'atténuation.

ZDI attribue à ces deux rapports ksmbd une note de 9,0 et les classe parmi les failles permettant l’exécution de code à distance, ce qui explique pourquoi ils ont fait la une de l’actualité. Les preuves de concept (PoC) rendues publiques démontrent une divulgation de mémoire du noyau et des plantages, plutôt qu’une exécution de code. Il s’agit là de véritables problèmes de sécurité en soi, et les résultats publiés ne reflètent pas toute l’étendue des possibilités dont disposerait un attaquant. ZDI mentionne également une voie d’écriture hors limites pour ZDI-CAN-33774 qui n’apparaît pas dans les documents publics.

C'est le niveau d'exposition qui détermine l'ampleur des dégâts. Ces deux failles se trouvent dans ksmbd, le serveur SMB intégré au noyau. Celui-ci est distinct de Samba, le serveur SMB en espace utilisateur utilisé par la plupart des serveurs de fichiers Linux ; les hôtes qui partagent des fichiers uniquement via Samba ne sont donc pas exposés à ces failles.

AlmaLinux ainsi que CloudLinux 9 et 10 ne compilent pas du tout ksmbd. Debian et Ubuntu le compilent, mais uniquement sur demande. Il ne fonctionne qu’après avoir été installé par un administrateur. ksmbd-tools, qui n'est pas présent par défaut, et lance le ksmbd service. Le rapport ZDI-CAN-33549 ajoute encore d'autres conditions. Il nécessite l'utilisation de SMB Direct sur un périphérique réseau RDMA, ainsi qu'un partage accessible en écriture via un compte utilisateur ou un accès invité. Ubuntu intègre SMB Direct, contrairement à Debian, et le matériel RDMA est rare sur les serveurs d'hébergement.

Si vous utilisez ksmbd, prenez la vulnérabilité ZDI-CAN-33774 très au sérieux. Elle est accessible via le réseau avant même la connexion, entraîne la fuite de 28 octets de la mémoire dynamique du noyau à chaque fois et peut provoquer le plantage de l'hôte. Namjae Jeon, responsable du projet ksmbd a répondu qu'il est déjà intégré dans son arbre sous la forme de valider 68f410faedaf, qui n'a pas encore été intégré à la branche principale. Si systemctl is-active ksmbd indique « inactif » et lsmod ne mentionne pas ksmbd, c'est un bon indice que le serveur ne fonctionne pas, mais assurez-vous qu'aucun autre service sur l'hôte ne l'ait lancé avant d'écarter cette possibilité. S'il est actif et qu'aucun autre service ne dépend de ce partage, arrêtez-le à l'aide de la commande systemctl disable --now ksmbd. Si ce partage est indispensable, évitez de l'utiliser sur des réseaux non fiables jusqu'à ce que des noyaux corrigés soient disponibles.

Le reste de la pile

ZDI-CAN-34068 correspond à une écriture hors limites dans vmwgfx, le pilote du GPU virtuel de VMware, classée comme une élévation de privilèges locale. ZDI-CAN-34076 correspond à une fuite de mémoire non initialisée dans nvmet, la cible NVMe over Fabrics. Ces deux vulnérabilités ne sont rendues publiques que par leur titre. En l'absence de détails techniques, il n'y a rien de concret à vérifier ou à corriger ; aucune mesure n'est donc prévue tant que des informations supplémentaires ne seront pas disponibles.

La vulnérabilité ZDI-CAN-32005 concerne ConnMan, un gestionnaire de réseau fonctionnant dans l'espace utilisateur. Il ne s'agit pas d'un bogue du noyau ; elle n'entre donc pas dans le champ d'application des correctifs fournis par KernelCare. Si vous utilisez ConnMan, surveillez les mises à jour via vos canaux de distribution habituels.

Aucune des deux mesures correctives ci-dessous n'a encore été validée en interne par rapport au PoC. Testez-les d'abord chacune sur un hôte de test pour identifier les éléments qui en dépendent, et ne considérez aucune d'entre elles comme un substitut à une véritable correction.

La solution principale consiste à désactiver les espaces de noms des utilisateurs sans privilèges. Le paramètre user.max_user_namespaces à 0 empêche la création de nouveaux espaces de noms d'utilisateurs, ce qui devrait bloquer la démonstration de concept publique, puisqu'elle repose sur la création d'un tel espace. Contrairement à la restriction AppArmor d'Ubuntu, il s'agit d'une limite stricte au niveau du noyau qu'aucun profil AppArmor ne peut contourner :

echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-zdi-33367.conf
sysctl --system

Les espaces de noms existants restent en place ; ainsi, tout ce qui s'exécute déjà au sein de l'un d'entre eux continue de fonctionner. Cela a toutefois un coût réel. Les conteneurs sans racine, les applications Flatpak et certaines zones de sécurité des navigateurs dépendent des espaces de noms utilisateur et peuvent cesser de fonctionner.

La version allégée désactive deux des modules les moins courants sur lesquels repose le PoC public, nlmon et act_pedit, lors du chargement via le mécanisme habituel des modules :

printf 'install nlmon /bin/false\ninstall act_pedit /bin/false\n' > /etc/modprobe.d/zdi-33367.conf
lsmod | grep -E '^(nlmon|act_pedit) '

Le lsmod Cette ligne vous indique simplement si l'un ou l'autre de ces modules est actuellement chargé. Si l'un d'eux apparaît, la nouvelle règle ne le déchargera pas. Vérifiez qu'aucun autre élément n'en dépend, puis déchargez ce module à l'aide de modprobe -r, ou planifier un redémarrage. Un résultat vide ne prouve toutefois pas que le bloc soit bien en place. Exécutez modprobe -n -v nlmon et modprobe -n -v act_pedit, et vérifier que les deux impriment le install /bin/false ligne. Cela confirme la configuration du module, mais ne signifie pas que l'exploitation a été bloquée. Peu de serveurs utilisent nlmon ou le pedit action dans tc, mais vérifiez avant de tirer des conclusions. Le fait de bloquer ces deux éléments ne suffira peut-être pas non plus à couvrir toutes les voies d'accès au bug. Tout ce que l'on sait, c'est que la preuve de concept (PoC) publique en a besoin. La PoC nécessite esp4 aussi ; donc, si un hôte n'utilise pas IPsec et que vous avez bloqué esp4 Pour « Dirty Frag » en mai dernier, vérifiez que le bloc est toujours en place.

La désactivation des espaces de noms utilisateur est la principale option ; commencez donc par là sur tout hôte qui peut s'en passer. Vérifiez d’abord ce qui s’exécute sur l’hôte. Sur les serveurs web, de messagerie, de bases de données et d’hébergement mutualisé, cette mesure est généralement envisageable, à condition qu’aucun service n’utilise de conteneurs sans privilèges root ou de sandboxing. Sur les runners d’intégration continue, les hôtes de compilation et les postes de travail des développeurs qui dépendent des espaces de noms utilisateur, la désactivation de ces deux modules constitue une solution de secours moins perturbatrice, mais elle peut laisser d’autres voies d’accès au bogue ouvertes. Donnez la priorité à ces hôtes lorsqu’un correctif applicable sans redémarrage sera disponible.

Vérifier un serveur en moins d'une minute

Trois commandes permettent de répondre à la plupart des questions :

sysctl user.max_user_namespaces
systemctl is-active ksmbd
lsmod | grep -E '^(ksmbd|nlmon|act_pedit) '

A 0 Dès le départ, les nouveaux espaces de noms utilisateur sont désactivés, ce qui devrait empêcher l'exploitation publique de se produire. inactive La deuxième ligne semble indiquer que ksmbd ne fonctionne pas, et la troisième ligne permet de vérifier si le ksmbd Le module ou l'un des deux modules bloquables est actuellement chargé. Sous Ubuntu 24.04 et versions ultérieures, ne tirez pas de conclusions hâtives de sysctl kernel.apparmor_restrict_unprivileged_userns. Le PoC a contourné cette restriction lors des tests. Il s'agit là d'indicateurs rapides, et non d'un test de sécurité complet. Pour une flotte, exécutez les mêmes lignes via l'outil qui gère déjà vos commandes ad hoc, qu'il s'agisse d'Ansible, de Salt ou simplement de ssh en boucle.

Le correctif sans redémarrage de KernelCare pour la vulnérabilité ZDI-CAN-33367 est désormais disponible pour les noyaux EL10 et EL9 sur AlmaLinux, CloudLinux, RHEL, Oracle Linux et Rocky Linux. Il s’appuie sur le candidat de correctif en amont, et TuxCare a vérifié qu’il bloquait l’exploit public. Le correctif pour EL10 est disponible à la fois dans le flux de production et dans ePortal. Le correctif pour EL9 est disponible dans le flux de production, mais pas encore dans ePortal. Le correctif pour EL8 est prêt à être publié, et le travail sur Debian et Ubuntu est en cours, sans date prévue pour l'instant. Les noyaux EL6 et EL7 ne sont pas vulnérables ; ils ne bénéficieront donc pas d'un correctif sans redémarrage pour ce bogue.

Sur EL9 et EL10, les hôtes bénéficiant des mises à jour automatiques de KernelCare récupèrent le correctif selon leur calendrier habituel ; vous pouvez également le télécharger immédiatement à l’aide de la commande `kcarectl –update`. Aucun redémarrage n'est nécessaire, ce qui est d'autant plus important ici que le bloc de modules mentionné ci-dessus peut en exiger un. Aucun identifiant CVE n'ayant été attribué, le TuxCare CVE Tracker n'affiche aujourd'hui aucune information concernant ces rapports. Dès que des identifiants seront disponibles, c'est là que s'affichera le statut des correctifs sans redémarrage pour chaque distribution.

Procurez-vous KernelCare Enterprise dès aujourd'hui →

Pourquoi une fuite comme celle-ci change la donne

La divulgation coordonnée a pour but de donner une longueur d'avance aux défenseurs, mais cette semaine, cette longueur d'avance était nulle.

Dans le cadre d'une divulgation coordonnée, les responsables de maintenance et les distributeurs disposent généralement d'un délai pour préparer des correctifs avant que les détails techniques ou le code de l'exploit ne soient rendus publics. Ici, l'ordre a été inversé : l'exploit a d'abord été mis en œuvre, puis corrigé. Ce délai entre la divulgation publique de l'exploit et la mise à jour de l'hôte est précisément ce que tout processus de correction s'efforce de réduire au minimum ; or, dans le cas de ZDI-CAN-33367, il s'est écoulé avant que quiconque n'ait pu réagir.

Le correctif en amont ne tardera pas à arriver, et il figure déjà dans la branche « networking ». Quelqu’un d’autre avait repéré ce bug une semaine plus tôt et envoyé un correctif, ce qui montre bien combien de personnes épluchent actuellement le même code du noyau. Il faut s’attendre à d’autres chevauchements de ce genre, et à davantage de bugs rendus publics avant qu’un noyau stable n’intègre le correctif.

Vérifiez donc dès aujourd’hui les espaces de noms utilisateur et désactivez-les partout où ils ne sont pas nécessaires. Vérifiez si quelqu’un a activé ksmbd et l’a oublié. Surveillez ensuite la mise à disposition de ce correctif pour les noyaux de votre distribution et déterminez à quelle vitesse vous pouvez l’appliquer à tous les hôtes exposés – soit par un correctif sans redémarrage, soit par un redémarrage, selon ce que votre parc informatique est réellement en mesure de supporter.

Procurez-vous KernelCare Enterprise dès aujourd'hui →

Comment s'est déroulée la semaine

Sources

Les sources principales de cet article sont les rapports ZDI originaux et les réponses des responsables sur les listes de diffusion publiques, notamment le rapport ZDI-CAN-33367, la réponse d’Eric Dumazet, le correctif skb_zerocopy, le fil de discussion ZDI-CAN-33774, le commit de correction de ksmbd et le rapport ConnMan, ainsi que la liste des avis de sécurité à venir de ZDI, la couverture médiatique de Phoronix, le guide de signalement des failles de sécurité du noyau, la politique de divulgation de ZDI, la documentation du noyau relative à ksmbd, l’article de Max Kellermann sur « Dirty Pipe », la divulgation de « Copy Fail », l’entrée NVD concernant « Dirty Frag », ainsi que les propres tests effectués par TuxCare sur les distributions mentionnées ci-dessus.