Greg Kroah-Hartman, responsable du soutien de la branche stable du noyau Linux, a d\u00e9cid\u00e9 d'interdire toute modification provenant de l'Universit\u00e9 du Minnesota au noyau Linux, ainsi que de revenir sur tous les patchs accept\u00e9s pr\u00e9c\u00e9demment et de les r\u00e9examiner. La raison de ce blocage r\u00e9side dans l'activit\u00e9 d'un groupe de recherche \u00e9tudiant la possibilit\u00e9 de promouvoir des vuln\u00e9rabilit\u00e9s cach\u00e9es dans le code de projets open source. Ce groupe a envoy\u00e9 des patchs contenant divers types d'erreurs, a observ\u00e9 la r\u00e9action de la communaut\u00e9 et a \u00e9tudi\u00e9 les moyens de tromper le processus de r\u00e9vision des modifications. Selon Greg, la r\u00e9alisation de telles exp\u00e9riences pour introduire des changements malveillants est inacceptable et contraire \u00e0 l'\u00e9thique. <\/p>\n
La raison de la blocage \u00e9tait l'envoi par les membres de ce groupe d'un patch qui ajoutait une v\u00e9rification du pointeur afin d'exclure d'\u00e9ventuels doubles appels de la fonction \u00ab free \u00bb. Vu le contexte d'utilisation du pointeur, cette v\u00e9rification \u00e9tait inutile. L'objectif de l'envoi de ce patch \u00e9tait d'\u00e9tudier si la modification erron\u00e9e passerait l'examen des d\u00e9veloppeurs du noyau. En plus du patch mentionn\u00e9, d'autres tentatives de d\u00e9veloppeurs de l'Universit\u00e9 du Minnesota d'apporter des modifications douteuses au noyau ont \u00e9galement \u00e9merg\u00e9, y compris celles li\u00e9es \u00e0 l'ajout de vuln\u00e9rabilit\u00e9s cach\u00e9es. <\/p>\n
L'exp\u00e9diteur des patchs a tent\u00e9 de justifier son action en disant qu'il testait un nouvel analyseur statique et que le changement \u00e9tait bas\u00e9 sur les r\u00e9sultats de cette v\u00e9rification. Cependant, Greg a soulign\u00e9 que les corrections propos\u00e9es ne sont pas caract\u00e9ristiques des erreurs d\u00e9tect\u00e9es par les analyseurs statiques, et tous les patchs envoy\u00e9s ne corrigeaient absolument rien. \u00c9tant donn\u00e9 que le groupe de chercheurs en question avait d\u00e9j\u00e0 essay\u00e9 par le pass\u00e9 de promouvoir des corrections avec des vuln\u00e9rabilit\u00e9s cach\u00e9es, il est \u00e9vident qu'ils ont poursuivi leurs exp\u00e9riences sur la communaut\u00e9 des d\u00e9veloppeurs du noyau. <\/p>\n
Il est int\u00e9ressant de noter qu'auparavant, le responsable du groupe menant les exp\u00e9riences avait particip\u00e9 \u00e0 la correction l\u00e9gitime de vuln\u00e9rabilit\u00e9s, par exemple en identifiant des fuites d'informations dans la pile USB (CVE-2016-4482) et dans la sous-syst\u00e8me r\u00e9seau (CVE-2016-4485). Dans l'\u00e9tude sur la promotion cach\u00e9e de vuln\u00e9rabilit\u00e9s, le groupe de l'Universit\u00e9 du Minnesota cite l'exemple de la vuln\u00e9rabilit\u00e9 CVE-2019-12819, caus\u00e9e par une correction adopt\u00e9e dans le noyau en 2014. La correction ajoutait un appel put_device dans le bloc de gestion des erreurs dans mdio_bus, mais cinq ans plus tard, il a \u00e9t\u00e9 r\u00e9v\u00e9l\u00e9 que ce type de manipulation conduit \u00e0 un acc\u00e8s \u00e0 un bloc m\u00e9moire apr\u00e8s sa lib\u00e9ration (\u00ab use-after-free \u00bb). <\/p>\n
Les auteurs de l'\u00e9tude affirment qu'ils ont g\u00e9n\u00e9ralis\u00e9 des donn\u00e9es sur 138 correctifs erron\u00e9s, non li\u00e9s aux participants de l'\u00e9tude. Les tentatives d'envoi de leurs propres correctifs comportant des erreurs se limitaient \u00e0 des \u00e9changes par email, et de tels changements n'ont pas \u00e9t\u00e9 int\u00e9gr\u00e9s dans Git (si, apr\u00e8s l'envoi d'un correctif par email, le mainteneur consid\u00e9rait le correctif comme normal, il \u00e9tait pri\u00e9 de ne pas inclure le changement en raison d'une erreur, apr\u00e8s quoi un correctif correct \u00e9tait renvoy\u00e9). <\/p>\n
Addendum 1 : \u00c0 en juger par l'activit\u00e9 de l'auteur du correctif critiqu\u00e9, il envoie des correctifs dans divers sous-syst\u00e8mes du noyau depuis longtemps. Par exemple, des modifications ont r\u00e9cemment \u00e9t\u00e9 accept\u00e9es dans les pilotes radeon et nouveau, avec l'appel pm_runtime_put_autosuspend(dev->dev) dans le bloc d'erreur, il n'est pas exclu que cela conduise \u00e0 l'utilisation d'un tampon apr\u00e8s la lib\u00e9ration de la m\u00e9moire qui lui est associ\u00e9e. <\/p>\n