Després d'una carta oberta de disculpes, un grup d'investigadors de la Universitat de Minnesota, l'acceptació dels quals dels canvis al nucli de Linux va ser bloquejada per Greg Croah-Hartman, va revelar informació detallada sobre els pegats enviats als desenvolupadors del nucli i la correspondència amb els mantenedors. relacionats amb aquests pegats.
Cal destacar que tots els pedaços problemàtics van ser rebutjats per iniciativa dels mantenedors, ni un sol pegat es va aprovar. Aquest fet deixa clar per què Greg Croah-Hartman va actuar tan durament, ja que no està clar què haurien fet els investigadors si els pegats haguessin estat aprovats pels mantenedors. En retrospectiva, van afirmar que tenien la intenció d'informar d'un error i que no haurien permès que els pegats anessin a Git, però no està clar què haurien fet realment i fins a quin punt podrien haver arribat.
Total a l'agost de 2020 a partir d'adreces anònimes [protegit per correu electrònic] и [protegit per correu electrònic] (carta de James Bond) es van enviar cinc pegats: dos correctes (1, 2) i tres que contenien errors ocults (1, 2, 3), creant condicions per a les vulnerabilitats. Cada pedaç contenia només 1-4 línies de codi. La idea principal darrere dels pegats erronis era que arreglar una fuita de memòria podria crear una doble condició de vulnerabilitat lliure. Una setmana més tard, es va enviar informació als desenvolupadors del nucli amb una proposta per discutir la possibilitat de promoure vulnerabilitats sota l'aparença de solucions trivials per a fuites de memòria, però no es va dir res sobre els intents anteriors d'enviar pedaços maliciosos.
El primer pedaç problemàtic va solucionar la fuita de memòria afegint una crida a kfree() abans de tornar el control en cas d'error, però va crear condicions per accedir a l'àrea de memòria després d'alliberar-la (ús després de lliure). Aquest pegat va ser rebutjat pel mantenidor (Jiri Slaby), que va identificar el problema i va assenyalar que fa un any algú ja havia intentat proposar un canvi similar i inicialment va ser acceptat, però després es va descartar després d'identificar les condicions de la vulnerabilitat. > p2 = p1[n] = kmalloc_array(64, sizeof(u16), GFP_KERNEL); > - si (!p2) retorna -ENOMEM; > + if (!p2) { > + kfree(p1); > + retornar -ENOMEM; > + }
El segon pedaç també contenia condicions per al problema de l'ús després de la lliure. El pedaç especificat no va ser acceptat pel mantenedor (Dan Carpenter), que va rebutjar el pedaç a causa d'un altre problema amb list_add_tail, però no es va adonar que el punter "chdev" es podia alliberar a la funció put_device, que s'utilitza a continuació a la trucada. dev_err(&chdev ->dev..). No obstant això, el pegat no va ser acceptat, encara que per motius no relacionats amb la vulnerabilitat. if (ret < 0) { + put_device(&chdev->dev); dev_err(&chdev->dev, DRV_NAME ": kfifo_alloc fallat\n"); ret = -ENOMEM; anar a err_fifo;
El tercer pedaç tampoc va ser acceptat pel mantenedor (Miquel Raynal) a causa d'un altre error no relacionat amb la vulnerabilitat (doble trucada per posar per pdev). if (!window->virt) { printk(KERN_ERR MOD_NAME ": ioremapa(%08lx, %08lx) ha fallat\n", finestra->phys, finestra->mida); + pci_dev_put(pdev); sortir fora; } ... if (!map) { printk(KERN_ERR MOD_NAME ": kmalloc ha fallat"); + pci_dev_put(pdev); sortir fora; } memset(mapa, 0, sizeof(*mapa)); ... if (mtd_device_register(mapa->mtd, NULL, 0)) { map_destroy(mapa->mtd); mapa->mtd = NULL; + pci_dev_put(pdev); sortir fora; }
Curiosament, inicialment es va suposar que 4 de cada 5 pegats tenien problemes, però els mateixos investigadors van cometre un error i en un pegat van pensar que era problemàtic, es va proposar una correcció correcta, sense les condicions esperades per a l'ús de la memòria després de la llibertat. err = pci_request_mem_regions (pdev, nom_driver_nitrox); if (err) { pci_disable_device (pdev); + dev_err(&pdev->dev, “No s'ha pogut sol·licitar les regions mem!\n”); tornar error; }
Font: opennet.ru