Po odprtem opravičilnem pismu je skupina raziskovalcev z Univerze v Minnesoti, ki jim je Greg Croah-Hartman preprečil sprejetje sprememb v jedru Linuxa, razkrila podrobne informacije o popravkih, poslanih razvijalcem jedra, in korespondenci z vzdrževalci povezanih s temi popravki.
Omeniti velja, da so bili vsi problematični popravki na pobudo vzdrževalcev zavrnjeni, niti en popravek ni bil odobren. To dejstvo pojasnjuje, zakaj je Greg Croah-Hartman ravnal tako ostro, saj ni jasno, kaj bi raziskovalci storili, če bi popravke odobrili vzdrževalci. Za nazaj so trdili, da so nameravali prijaviti napako in ne bi dovolili, da bi popravki šli v Git, vendar ni jasno, kaj bi dejansko storili in kako daleč bi lahko šli.
Skupaj avgusta 2020 z anonimnih naslovov [e-pošta zaščitena] и [e-pošta zaščitena] (pismo Jamesa Bonda) je bilo poslanih pet popravkov: dva pravilna (1, 2) in trije, ki vsebujejo skrite napake (1, 2, 3), kar ustvarja pogoje za ranljivosti. Vsak popravek je vseboval samo 1-4 vrstice kode. Glavna zamisel napačnih popravkov je bila, da bi odpravljanje puščanja pomnilnika lahko ustvarilo stanje dvojne proste ranljivosti. Teden dni kasneje so bile razvijalcem jedra poslane informacije s predlogom za razpravo o možnosti spodbujanja ranljivosti pod krinko trivialnih popravkov za puščanje pomnilnika, vendar ni bilo nič omenjenih o prejšnjih poskusih pošiljanja zlonamernih popravkov.
Prvi problematični popravek je odpravil uhajanje pomnilnika z dodajanjem klica kfree() pred vrnitvijo nadzora v primeru napake, vendar je ustvaril pogoje za dostop do območja pomnilnika, potem ko je bilo osvobojeno (use-after-free). Ta popravek je zavrnil vzdrževalec (Jiri Slaby), ki je prepoznal težavo in poudaril, da je pred enim letom nekdo že poskušal predlagati podobno spremembo in je bila sprva sprejeta, nato pa zavržena, ko je ugotovila pogoje za ranljivost. > p2 = p1[n] = kmalloc_array(64, sizeof(u16), GFP_KERNEL); > - če (!p2) vrni -ENOMEM; > + if (!p2) { > + kfree(p1); > + return -ENOMEM; > +}
Drugi popravek je vseboval tudi pogoje za težavo uporabe po brezplačni uporabi. Vzdrževalec (Dan Carpenter) ni sprejel navedenega popravka, ki je zavrnil popravek zaradi druge težave z list_add_tail, vendar ni opazil, da bi se kazalec "chdev" lahko sprostil v funkciji put_device, ki se uporablja spodaj pri klicu dev_err(&chdev ->dev..). Vendar popravek ni bil sprejet, čeprav iz razlogov, ki niso povezani z ranljivostjo. if (ret < 0) { + put_device(&chdev->dev); dev_err(&chdev->dev, DRV_NAME ": kfifo_alloc ni uspelo\n"); ret = -ENOMEM; goto err_fifo;
Vzdrževalec (Miquel Raynal) prav tako ni sprejel tretjega popravka zaradi druge napake, ki ni povezana z ranljivostjo (dvojni klic, da se postavi za pdev). if (!window->virt) { printk(KERN_ERR MOD_NAME ": ioremap(%08lx, %08lx) ni uspelo\n", window->phys, window->size); + pci_dev_put(pdev); iti ven; } ... if (!map) { printk(KERN_ERR MOD_NAME ": kmalloc ni uspel"); + pci_dev_put(pdev); iti ven; } memset(map, 0, sizeof(*map)); ... if (mtd_device_register(map->mtd, NULL, 0)) { map_destroy(map->mtd); zemljevid->mtd = NULL; + pci_dev_put(pdev); iti ven; }
Zanimivo je, da so sprva domnevali, da imajo 4 od 5 popravkov težave, vendar so se raziskovalci sami zmotili in v enem popravku, ki je bil po njihovem mnenju problematičen, je bil predlagan pravilen popravek, brez pričakovanih pogojev za uporabo pomnilnika po sprostitvi. napaka = pci_request_mem_regions(pdev, nitrox_driver_name); if (err) { pci_disable_device(pdev); + dev_err(&pdev->dev, “Zahtevanje regij mem ni uspelo!\n”); vrni napako; }
Vir: opennet.ru