Fin d’un cycle pour le noyau Linux. Le 20 juin 2026, Linus Torvalds a fusionné dans Linux 7.2 un patch attendu depuis six ans : la suppression totale de strncpy(), une fonction C vieille de plusieurs décennies qualifiée de « source persistante de bugs » par les développeurs eux-mêmes.
Une fonction qui ne garantissait rien
strncpy() servait à copier un nombre défini d’octets d’un tampon mémoire vers un autre. En théorie, un outil banal. En pratique, un piège que les mainteneurs du noyau traquent depuis des années. Quand la chaîne source atteint ou dépasse la taille du tampon de destination, strncpy() omet le caractère nul de terminaison. Tout code qui lit ensuite ce tampon comme une chaîne classique continue de parcourir la mémoire au-delà de la zone allouée, exposant potentiellement des données sensibles du noyau.
Le comportement est hérité des premières implémentations du langage C dans les années 1970, où la gestion de la mémoire se faisait sans filet. strncpy() était censée corriger les failles de sa grande soeur strcpy(), qui ne vérifiait aucune limite de taille. Mais son implémentation a introduit un nouveau type de vulnérabilité : en omettant le caractère nul de terminaison dans certains cas, elle créait des chaînes non terminées qui provoquent des dépassements de tampon lors de la lecture ultérieure.
À l’inverse, quand la source est plus courte que la destination, strncpy() remplit l’espace restant avec des zéros, gaspillant des cycles CPU pour un remplissage qui n’a aucune utilité pratique. Ce comportement à double tranchant en faisait un terreau fertile pour les bugs de sécurité, les buffer overflows et les fuites d’information mémoire, particulièrement dangereux dans un contexte noyau où la moindre faille ouvre un accès privilégié à l’attaquant.
Le projet, orchestré par l’ingénieur Google Kees Cook dans le cadre du Kernel Self Protection Project, a mobilisé 70 contributeurs pendant six ans. Justin Stitt a signé à lui seul 211 des 362 commits nécessaires, migrant chaque appel vers l’une des cinq fonctions de remplacement : strscpy, strscpy_pad, strtomem_pad, memcpy_and_pad, memcpy. Cinq alternatives, parce que le noyau détournait strncpy() pour cinq opérations sémantiquement distinctes, amalgamées sous un même nom trompeur.
Le Kernel Self Protection Project (KSPP), lancé par Kees Cook en 2017, vise à durcir le noyau Linux contre les attaques mémoire. Il a déjà supervisé l’élimination de nombreuses classes de vulnérabilités : déréférencement de pointeurs nuls, débordements sur la pile, utilisation après libération. La suppression de strncpy() en est le chapitre le plus volumineux à ce jour par le nombre de fichiers touchés.
362 commits, six ans, zero regret
Le merge tag fusionné par Torvalds le 19 juin 2026 porte le nom strncpy-removal-v7.2-rc1. Le tableau d’honneur des 70 contributeurs, visible dans le commit sur le dépôt officiel de Torvalds, liste les noms de ceux qui ont rendu cette suppression possible. L’ampleur du chantier est spectaculaire : retrait des implémentations architecturales spécifiques dans alpha, m68k, powerpc, x86 et xtensa, chacune avec ses propres variantes assembleur.
Chaque architecture implémentait strncpy() à sa manière, parfois en assembleur optimisé, parfois en C. L’équipe de Kees Cook a dû non seulement retirer ces implémentations, mais aussi s’assurer qu’aucun code assembleur ne faisait référence à la fonction de manière détournée. Le dépôt git de Torvalds enregistre 362 commits sur la branche strncpy-removal-v7.2-rc1, reflétant la complexité du travail.
L’effort ne s’est pas limité à effacer une fonction. Chaque appel à strncpy() dans le noyau a été remplacé manuellement par l’alternative appropriée. Les cas où la fonction servait à copier des données binaires ont reçu memcpy() ou memcpy_and_pad(). Ceux où une chaîne tronquée était acceptable ont migré vers strscpy(). Les cas litigieux où le comportement exact de strncpy() était intentionnellement utilisé ont été réécrits pour être explicites et vérifiables par relecture de code.
Ce qui change pour les développeurs
Conséquence concrète : toute tentative d’invoquer strncpy() dans un futur patch du noyau provoquera désormais une erreur de compilation. Ce qui relevait de la recommandation devient une règle architecturale gravée dans le code. Les développeurs qui soumettent des correctifs devront utiliser l’une des cinq fonctions de remplacement, sous peine de voir leur patch refusé par le compilateur.
Cette approche est cohérente avec la philosophie du noyau Linux : les erreurs détectées à la compilation coûtent zero temps d’exécution et ne peuvent pas être exploitées en production. Le compilateur GCC dispose déjà d’attributs comme __attribute__((error)) qui permettent de marquer des symboles interdits et de produire une erreur à la compilation. La suppression de strncpy() ne changera rien pour les logiciels en espace utilisateur, qui conservent leur accès à la fonction via la bibliothèque C standard. C’est une décision ciblée, propre au noyau, où la moindre vulnérabilité mémoire peut compromettre l’intégralité du système.
Calendrier et perspectives
Linux 7.2 devrait entrer en release candidate le 28 juin 2026, avec une version finale attendue fin août 2026. Le chantier ouvert par Kees Cook et ses 70 contributeurs pourrait inspirer d’autres nettoyages similaires : des fonctions héritées comme strcpy() ou gets() sont encore utilisées dans certaines parties du code, même si leur dangerosité est connue depuis les années 1990.
Torvalds, qui a fusionné le patch sans commentaire particulier, a validé une approche que la communauté du noyau poursuit depuis 2020 : remplacer systématiquement les fonctions C non sécurisées sans attendre une réécriture complète. Une stratégie pragmatique qui porte ses fruits, un commit à la fois.
