Le patch que Linux a laissé dormir six ans

Comment une proposition de Jann Horn en 2020 aurait pu éviter CVE-2026-46333

Le 14 mai 2026, Linus Torvalds intègre dans le noyau Linux un commit au titre presque débonnaire : « ptrace: slightly saner ‘get_dumpable()‘ logic ». Quelques heures plus tard, deux exploits fonctionnels apparaissent sur GitHub, baptisés ssh-keysign-pwn et chage_pwn. La faille corrigée, désormais référencée CVE-2026-46333, permet à n’importe quel utilisateur local non privilégié de lire les clés SSH privées d’un serveur et le fichier /etc/shadow. Qualys, qui a signalé la vulnérabilité aux mainteneurs du noyau, parle d’un bug logique vieux d’environ six ans.

Six ans, c’est précisément l’âge d’un courriel oublié.

Le 16 octobre 2020, Jann Horn — chercheur au Google Project Zero, l’un des analystes sécurité les plus respectés au monde sur les bugs noyau — poste sur la liste de diffusion LKML deux séries de patches. Les références figurent encore dans l’archive publique de lore.kernel.org : 20201016024019.1882062-1-jannh@google.com et 20201016230915.1972840-1-jannh@google.com. Horn y décrit déjà le mécanisme qui sera exploité en mai 2026 : la fonction __ptrace_may_access() du noyau ignore le contrôle « dumpable » lorsque le champ task->mm est à NULL, c’est-à-dire pendant la fenêtre où un processus en cours de terminaison a libéré son mappage mémoire mais conserve encore ses descripteurs de fichiers ouverts. La logique, écrit-il en substance, est « dubious from a security perspective » — douteuse du point de vue de la sécurité.

Le patch n’a jamais été fusionné.

Comment la redécouverte s’est faite

L’histoire de cette redécouverte est presque aussi instructive que la faille elle-même. Quand Qualys publie son avis sur la liste oss-security le 15 mai 2026, le post se contente d’annoncer le bug et le correctif. C’est dans le fil de discussion qui suit, sur X, autour d’une analyse brève publiée par Brad Spengler (grsecurity), qu’un participant nommé Altan Baig fait remarquer que Jann Horn avait déjà proposé un patch équivalent cinq ans et demi plus tôt. Qualys reprend l’information dans un message de suivi sur oss-security. The Register relaie ensuite : « The problem with tracking security reports, which Penguin Emperor Torvalds described recently, is not new, alas. »

Autrement dit, personne dans la chaîne — ni les mainteneurs du sous-système ptrace, ni Qualys lors de son enquête, ni les distributions qui vont devoir patcher en urgence — ne disposait initialement de cette mémoire institutionnelle. Il a fallu qu’un internaute fasse le rapprochement sur un réseau social pour qu’on réalise que le bug avait déjà été signalé, analysé et corrigé sur papier, par l’une des sommités du domaine, en 2020.

Ce qu’on ne sait pas (et qu’il faut admettre)

Tentation journalistique évidente : raconter l’histoire d’un patch ignoré par négligence, voire d’un avertissement délibérément balayé. La réalité publique est plus opaque. Les archives LKML montrent que Horn a posté ses patches ; elles ne montrent pas avec la même clarté pourquoi le travail n’a pas abouti. Plusieurs scénarios sont compatibles avec ce qu’on sait :

• L’enlisement technique. Les patches touchant __ptrace_may_access() interagissent avec des mécanismes anciens du noyau (LSM, Yama, sémantique POSIX du drapeau dumpable). Une proposition peut générer des objections de fond — risques de régression, sémantique de bord, performances — qui exigent une refonte, et la refonte se perd dans les priorités du contributeur.
• Le défaut de relayeur. En l’absence d’un mainteneur de sous-système qui prend la balle au bond, un patch même excellent peut rester en suspens. Le sous-système ptrace n’a pas de mainteneur dédié unique ; Oleg Nesterov fait la plus grande partie du travail, mais il n’a pas l’obligation formelle de fusionner ce qui lui parvient.
• La sous-estimation de l’exploitabilité. En 2020, l’angle d’attaque pratique — combiner ce bug logique avec pidfd_getfd(2) pour voler des descripteurs de fichiers à un binaire SUID-root en cours d’arrêt — n’était peut-être pas évident. pidfd_getfd(2) lui-même venait d’être ajouté (Linux 5.6, mars 2020). Un patch défensif sans démonstration d’exploit attire moins l’attention qu’un patch accompagné d’un PoC.

Aucune de ces hypothèses n’est démontrée publiquement. Il faudrait pour cela une enquête fine dans les archives LKML d’octobre 2020 à 2022 — combien de relectures, quelles objections, quels échanges privés sur security@kernel.org — qui n’a, à ma connaissance, pas encore été menée par la presse technique.

Le vrai problème : le pipeline de revue

Ce qui s’est passé n’est pas une anomalie isolée. C’est la manifestation d’un phénomène structurel que Torvalds lui-même a évoqué récemment : Linux n’a pas de système de suivi rigoureux des rapports de sécurité. Quand Greg Kroah-Hartman intègre un correctif dans une branche LTS, ou quand un chercheur poste une analyse défensive sur LKML, il n’existe pas d’instance qui garantisse que la proposition soit revue, tracée, et soit fusionnée soit explicitement rejetée avec motif. Les patches peuvent disparaître par épuisement — celui qui les a écrits passe à autre chose, personne d’autre ne reprend.

Pour les bugs sécurité, le problème est aggravé par la culture du noyau qui répugne historiquement à traiter les failles différemment des autres bugs. Cette posture a sa cohérence intellectuelle : tout bug du noyau est en théorie une faille potentielle, et un système de signalement parallèle créerait deux classes de patches, ce qui ouvrirait son propre lot de complications. Mais elle a un coût pratique, démontré ici en grandeur réelle : un patch défensif posté par un chercheur de premier plan peut sommeiller pendant que la primitive exploitable reste accessible à quiconque sait la chercher.

Ce que coûte un patch oublié

Entre octobre 2020 et mai 2026, chaque distribution Linux majeure a expédié des noyaux vulnérables. AlmaLinux 8, 9 et 10 ; Debian 11, 12 et 13 ; Ubuntu 22.04, 24.04 et 26.04 ; Arch ; Raspberry Pi OS Bookworm ; les familles EL9 et EL10. Le PoC public fonctionne out of the box sur des installations par défaut. Combien d’attaquants ont, dans l’intervalle, redécouvert le même mécanisme sans le publier ? Impossible de le dire. La présomption raisonnable, dans une communauté qui inclut autant des chercheurs académiques que des acteurs étatiques, est que la fenêtre n’est pas restée fermée pendant cinq ans et demi.

L’argument selon lequel « la faille n’a pas été exploitée puisque personne n’en parle » n’est pas un argument. L’exploitation locale, contre une machine de production multi-tenant ou un poste de développeur, laisse rarement des traces publiques. Et le fait qu’il a fallu attendre qu’un chercheur tiers signale le précédent de Horn pour que la communauté en prenne acte indique précisément à quel point la traçabilité fait défaut.

La leçon que personne n’a vraiment envie de tirer

L’épisode arrive dans une fenêtre déjà chargée pour le noyau Linux : trois autres failles locales (Copy Fail le 29 avril, Dirty Frag le 7 mai, Fragnesia le 13 mai) ont précédé ssh-keysign-pwn en moins de trois semaines. Le réflexe médiatique a été de regrouper le tout sous l’étiquette « avalanche de failles Linux », ce qui amalgame des bugs de nature très différente.

Le vrai motif commun, lui, est ailleurs. Les trois premières failles relèvent d’erreurs de programmation classiques dans le sous-système XFRM/ESP — des bugs qu’on découvre, qu’on corrige, qu’on documente. CVE-2026-46333 est qualitativement différente : c’est un bug qui avait été découvert et corrigé sur papier par l’un des meilleurs chercheurs du monde, et que le processus de revue du noyau a laissé tomber. La première catégorie nous dit quelque chose sur la difficulté d’écrire du C sans erreur. La seconde nous dit quelque chose sur la gouvernance d’un projet open source devenu infrastructure critique mondiale.

Aucune des deux n’est rassurante. Mais elles n’appellent pas les mêmes réponses. Pour les bugs de codage, on a des outils : fuzzers, analyse statique, harness de test, KASAN, syzkaller. Pour les patches oubliés, on n’a presque rien — sinon la mémoire d’individus, la culture d’une liste de diffusion, et l’espoir qu’un internaute averti fasse le rapprochement au bon moment sur un réseau social.

C’est cet écart-là, plus que le bug lui-même, qui mérite qu’on s’y attarde.

Sources principales : avis Qualys sur oss-security du 15 mai 2026 ; commit 31e62c2ebbfd du noyau Linux ; archives LKML d’octobre 2020 (messages 20201016024019.1882062-1-jannh@google.com et 20201016230915.1972840-1-jannh@google.com) ; analyse de Brad Spengler (grsecurity) ; couverture de The Register, Phoronix, LWN, AlmaLinux et OSTechNix.