Pourquoi je construis ma propre pile

Le 29 avril 2026, je tombe sur la CVE-2026-31431.

Je suis dev de base. Pas chercheur en sécurité, pas spécialiste noyau. Mais je lis les titres, et celui-là me fait cliquer : “Copy Fail”. CVSS 7.8. Escalade de privilèges locale dans le noyau Linux.

Je commence à lire et je ne comprends pas la moitié. algif_aead. AF_ALG. scatterlist. splice().

Je cherche et plus je cherche, plus je descends… Une couche après l’autre.

Ce qui est fascinant, c’est que la faille n’est pas un bug isolé. Trois décisions indépendantes qui, ensemble, créent quelque chose d’exploitable.

2011 : un wrapper AEAD est introduit pour IPsec. Il déborde de 4 octets en dehors de sa zone mémoire lors du déchiffrement. C’est crade, mais totalement confiné dans le noyau. Aucun risque.

2015 : les sockets AF_ALG arrivent. Désormais, un processus non-privilégié peut accéder au sous-système crypto du noyau, y compris ce wrapper AEAD. On vient d’exposer vers l’extérieur un composant qui avait une petite bizarrerie interne.

2017 : le commit 72548b093ee3. Une optimisation dans algif_aead.c, les buffers d’entrée et de sortie sont fusionnés pour traiter les données en place. Ce débordement de 4 octets qui était inoffensif se retrouve maintenant dans des zones mémoire contrôlables depuis l’espace utilisateur. La faille est en place. Elle restera là, silencieuse, pendant neuf ans.

Un socket AF_ALG AEAD est ouvert. Le binaire /usr/bin/su est lu dans le page cache. Grâce au débordement des 4 octets dans algif_aead.c et à splice(), l’exploit écrit des données contrôlées dans le page cache, par blocs de 4 octets, à l’offset précis du binaire en mémoire. La copie disque est intacte. Le noyau ne sait pas que le page cache a été altéré. Quand quelqu’un exécute su, le noyau sert la version corrompue depuis la RAM. su étant setuid root, le shell se lance en root.

Le correctif principal arrive le 1er avril 2026 dans la branche de développement. Mais au moment de la divulgation publique, le 29 avril, les versions LTS du noyau utilisées par Debian, Red Hat, Ubuntu n’ont pas encore de patch. Les distributions apprennent l’existence de la faille en même temps que tout le monde, avec un PoC qui tourne déjà.

Ce moment où je réalise que je ne suis pas maître de mon OS.

La méfiance que j’avais déjà

C’est une position philosophique autant qu’une gêne viscérale. Cette sensation de travailler sur quelque chose qui tient debout par des abstractions de plus en plus hautes, et de ne jamais vraiment savoir ce qu’il y a dessous.

CVE-2026-31431 n’a pas créé cette méfiance. Elle lui a donné un exemple concret, documenté, public.

Ce qui me frappe dans cette faille, c’est qu’elle est banale. Une optimisation locale, raisonnable au moment où elle a été écrite, avec des effets que personne n’avait tracés jusqu’au bout. Le noyau Linux est audité par des milliers de personnes depuis des décennies. Et une décision de 2017 est restée là, silencieuse, jusqu’en 2026.

Je sais aussi que l’IA va accélérer tout ça. On va découvrir des failles tous les jours. Mes projets ne seront jamais aussi solides que ce que font les équipes qui maintiennent le noyau depuis des années. Je n’ai pas d’illusions là-dessus.

Mais ce n’est pas le but.

Ce que j’ai décidé de faire

Je veux construire. Pas pour faire mieux que Linux. Je n’aurais pas les ressources ni les années d’expérience des milliers de développeurs qui maintiennent le noyau. LFS ne va pas faire de moi un expert en C. Writing an OS in Rust ne va pas me rendre meilleur que les équipes qui font Firecracker ou Cloud Hypervisor.

Je vais comprendre ce qui se passe en dessous. Et c’est exactement ce que je veux.

Parce que construire force à prendre des décisions que la documentation ne prend pas pour toi. Pourquoi cette syscall et pas une autre. Pourquoi cette structure mémoire. Pourquoi cette optimisation dans ce sous-système.

La décision s’est posée en trois étapes.

D’abord, Linux From Scratch. Construire un système Linux complet à partir des sources : toolchain croisée, glibc, noyau, tout. Pas pour avoir un Linux personnalisé. Pour ne plus jamais regarder un système en me demandant ce qui le fait tenir debout.

Ensuite, un noyau bare-metal en Rust. Les travaux de Philipp Oppermann. Gestion mémoire, interruptions, processus. Le bas de la pile, sans filet.

Et au bout : KyernalOs. Un noyau minimaliste pour faire tourner mes microVMs. Avec Kyerkle pour le stockage, et Kyctl pour orchestrer le tout.

Ce que cette série va documenter

Cet article est le premier d’une très longue suite. Une suite qui ne prendra surement jamais fin.

Ce n’est pas un tutoriel. C’est un journal. Chaque épisode documente une étape pendant que je la vis, les décisions, les erreurs, les détours. Je ne sais pas encore tout ce que je vais rencontrer, et c’est exactement pour ça que j’écris.

Si tu veux suivre quelqu’un qui descend dans les profondeurs parce qu’il n’arrive plus à s’en empêcher, tu es au bon endroit.

L’épisode suivant commence avec LFS. Une toolchain croisée, un compilateur qui se compile lui-même, et beaucoup de questions sur ce qu’on prend pour acquis.