Dans le noyau Linux 7.2, la suppression du vieux strncpy a réclamé un audit gigantesque
2 min
Logiciel
Logiciel
Depuis des décennies, les développeurs Linux utilisent une fonction nommée strncpy pour copier du texte. Développée en C, elle est étiquetée comme dangereuse par la propre documentation du noyau. Problème, elle est omniprésente.
Pour comprendre le problème, on peut utiliser une analogie. Supposons que la mémoire de l’ordinateur est comme une série de casiers. Quand un programme veut enregistrer un texte, il réserve une boite d’une certaine taille et y écrit le texte. En langage C, l’ordinateur n’a pas de moyen « naturel » pour savoir quand le mot s’arrête. Il y a donc une règle simple : quand le programme écrit un texte, il faut qu’un point rouge (caractère de fin de chaîne \0) en signale la fin.
Et c’est là que les ennuis commencent. La fonction strncpy() est responsable de la copie des textes, mais elle a un gros défaut : quand le texte est trop long, elle coupe la séquence de caractères, mais oublie d’ajouter un point. Et quand le texte est trop court ? Elle ajoute autant de points rouges que nécessaire pour remplir le champ réservé. Les conséquences vont du gaspillage d’énergie à la fuite de secrets, car l’absence de point rouge entraine l’application ou le service à lire ce qui se trouve au-delà, donc des informations présentes dans d’autres « casiers ».
Ces problèmes sont connus depuis longtemps, mais leur résolution a demandé un vaste effort d’ingénierie. Des développeurs ont ainsi passé les six dernières années à référencer toutes les occurrences de la fonction strncpy dans l’intégralité du code du noyau, totalisant 362 commits (des participations, en quelque sorte), rapporte Phoronix. La version 7.2 à venir sera donc la première à ne plus posséder strncpy, remplacé par des variantes modernes et beaucoup plus sécurisées.
Dans la plupart des cas, il s’agira de strscpy, qui possède le comportement adapté : l’outil copie du texte, mais si la séquence est trop longue, il la tronçonne en ajoutant systématiquement un point rouge à la fin de chaque morceau. Strncpy est donc supprimé définitivement à partir du prochain noyau, avec impossibilité d’y faire appel.
Commentaires (13)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles d'un média expert
Profitez d'au moins 1 To de stockage pour vos sauvegardes
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousAujourd'hui à 12h52
Dans le commit en lien (qui est le dernier de ce chantier), il y a la fonction en assembleur pour plusieurs architectures et en C plus un programme de test (qui teste la fonction il me semble).
Modifié aujourd'hui à 13h24
A priori, je dirais déjà dans tout ce qui a trait aux système de fichiers et en particulier les virtuels (comme
/procet/sys), un certain nombre de pilotes doit aussi y faire appel (je pense aux descripteurs USB mais il y a sans doute d’autres cas d’usage).La curiosité l’a emporté donc après clone du dépôt (3.21 Gio téléchargés quand même) et recherche rapide, je trouve grossièrement les zones suivantes :
drivers/(video, crypto, nfc, net pour les derniers traités).dmesget compagnie).fs/.sound/.J’ai arrêté de remonter l’historique vers début juillet 2025 et je n’ai pas regardé le détail de tous les commits mais les nom de périphérique et autres système apparaissent beaucoup, ce qui pourrait confirmer l’hypothèse
/sysou/devaussi.Modifié aujourd'hui à 13h03
Aujourd'hui à 13h04
Ca doit rentrer là-dedans, non ?
Aujourd'hui à 13h19
Par exemple dans le kernel, tu as la struct suivante pour la gestion des chaînes de caractères dans le cas du système de tracing.
struct seq_buf {
char *buffer;
size_t size;
size_t len;
loff_t readpos;
};
Et comme tu peux le voir, on a bien ici une chaine de caractère et sa taille (size).
Pour ta confusion, peut-être as-tu confondu avec les flottants et/ou les unités vectorielles, qui sont plus rarement présentes au sein d'un noyau.
Aujourd'hui à 13h24
grep -ri strncpy linux-6.12.68/ | wc -l
508
Donc, oui, y'a un besoin même si rapporté à tout le noyau et ses modules c'est pas si énorme et qu'il n'y a pas que du code et de quasi duplicats liés aux architectures supportées, dans ce chalutage. C'est surtout dans les tools, systèmes de traces/filtrage, variantes chaînes des copy to/from user...
Aujourd'hui à 13h32
strscpyne remplace pas uniquementstrncpy, j’ai vustrcpy,snprintfet potentiellement d’autres (ma recherche de commits était sur le remplaçant plus que le remplacé).Aujourd'hui à 13h37
Dans un micro-noyau, probablement que beaucoup de ces trucs seraient effectivement dans l’espace utilisateur. Mais on parle de Linux ici…
Aujourd'hui à 13h22
Du coup pourquoi strncpy n'a pas été dépréciée, depuis le temps?
Aujourd'hui à 13h34
Pour les chaines pascal, oui c’est une bonne idée, mais au final ça génère du code légèrement plus gros (un pointeur + une taille au lieu d’un pointeur à passer en paramètre). Le meilleur compromis aujourd’hui serait plutôt les german strings, mais il faut faire une analyse sur la topologie des chaînes utilisées pour voir si ça vaut vraiment le coup. Sur des mots, c’est hyper rentable, sur des descripteurs comme ceux utilisés dans le noyau linux, c’est peut-être plus discutable.
Aujourd'hui à 13h35
Il y a 45 minutes
À l'instant
Ici il doit y avoir des appels par centaines, pour atteindre 362 commits. Mais je vois pas où est la nouveauté.
Sur mon projet au taf (projet qui a plus de 20 ans, ~2M de lignes de codes sans compter les dépendances) on a déjà eu à faire ce chantier. C'est surtout le service test qui a transpiré, ces feignasses de dévs ont des outils pour automatiser la recherche et le remplacement
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?