Greg Kroah-Hartman, responsable de la maintenance de la branche stable du noyau Linux, a décidé d'interdire l'acceptation de toute modification provenant de l'Université du Minnesota dans le noyau Linux, ainsi que d'annuler tous les correctifs précédemment acceptés et de les réviser. La raison du blocage était les activités d'un groupe de recherche étudiant la possibilité de promouvoir des vulnérabilités cachées dans le code des projets open source. Ce groupe a soumis des correctifs contenant différents types de bugs, a observé la réaction de la communauté et a étudié les moyens de tromper le processus de révision des modifications. Selon Greg, mener de telles expériences pour introduire des changements malveillants est inacceptable et contraire à l’éthique.
La raison du blocage était que les membres de ce groupe avaient envoyé un patch qui ajoutait une vérification de pointeur pour éliminer l'éventuel double appel de la fonction « free ». Compte tenu du contexte d’utilisation du pointeur, la vérification était inutile. Le but de la soumission du correctif était de voir si la modification erronée serait examinée par les développeurs du noyau. En plus de ce correctif, d'autres tentatives de développeurs de l'Université du Minnesota ont fait surface pour apporter des modifications douteuses au noyau, notamment celles liées à l'ajout de vulnérabilités cachées.
Le participant qui a envoyé les correctifs a tenté de se justifier en disant qu'il testait un nouvel analyseur statique et que le changement avait été préparé sur la base des résultats des tests effectués. Mais Greg a attiré l'attention sur le fait que les correctifs proposés ne sont pas typiques des erreurs détectées par les analyseurs statiques, et que tous les correctifs envoyés ne corrigent rien du tout. Étant donné que le groupe de recherche en question a tenté par le passé de proposer des correctifs pour les vulnérabilités cachées, il est clair qu'il a poursuivi ses expériences avec la communauté de développement du noyau.
Il est intéressant de noter que dans le passé, le chef du groupe menant les expériences a été impliqué dans des correctifs légitimes de vulnérabilités, par exemple en identifiant des fuites d'informations dans la pile USB (CVE-2016-4482) et le sous-système réseau (CVE-2016-4485). . Dans une étude sur la promotion des vulnérabilités furtives, une équipe de l'Université du Minnesota cite l'exemple du CVE-2019-12819, provoqué par un correctif du noyau publié en 2014. Le correctif a ajouté un appel à put_device au bloc de gestion des erreurs dans mdio_bus, mais cinq ans plus tard, il est apparu qu'une telle manipulation conduit à l'accès au bloc mémoire après sa libération (« utilisation après libération »).
Dans le même temps, les auteurs de l'étude affirment que dans leur travail, ils ont résumé les données de 138 correctifs qui introduisaient des erreurs et n'étaient pas liés aux participants à l'étude. Les tentatives d'envoi de leurs propres correctifs avec des erreurs se limitaient à la correspondance par courrier électronique, et ces modifications n'entraient pas dans Git (si, après avoir envoyé le correctif par courrier électronique, le responsable considérait le correctif comme normal, il lui était alors demandé de ne pas inclure le changement car il était une erreur, après quoi ils ont envoyé le correctif correct).
Ajout 1 : à en juger par l'activité de l'auteur du correctif critiqué, il envoie depuis longtemps des correctifs à divers sous-systèmes du noyau. Par exemple, les pilotes radeon et nouveau ont récemment adopté des modifications avec un appel à pm_runtime_put_autosuspend(dev->dev) dans un bloc d'erreur, provoquant éventuellement l'utilisation du tampon après avoir libéré la mémoire qui lui est associée.
Addendum 2 : Greg a annulé 190 commits associés à "@umn.edu" et a lancé une nouvelle révision de ceux-ci. Le problème est que les membres avec des adresses "@umn.edu" ont non seulement expérimenté la diffusion de correctifs douteux, mais ont également corrigé de véritables vulnérabilités, et l'annulation des modifications pourrait entraîner le retour de problèmes de sécurité précédemment corrigés. Certains responsables ont déjà revérifié les modifications annulées et n'ont trouvé aucun problème, mais l'un des responsables a indiqué que l'un des correctifs qui lui avaient été envoyés contenait des erreurs.
Source: opennet.ru