În urma unei scrisori deschise de scuze, un grup de cercetători de la Universitatea din Minnesota, a cărui acceptare a modificărilor aduse nucleului Linux a fost blocată de Greg Croah-Hartman, a dezvăluit informații detaliate despre patch-urile trimise dezvoltatorilor de kernel și corespondența cu întreținerii. legate de aceste plasturi.
Este de remarcat faptul că toate patch-urile problematice au fost respinse la inițiativa întreținătorilor; nici măcar un singur patch nu a fost aprobat. Acest fapt arată clar de ce Greg Croah-Hartman a acționat atât de dur, din moment ce nu este clar ce ar fi făcut cercetătorii dacă patch-urile ar fi fost aprobate de menținători. În retrospectivă, ei au susținut că intenționează să raporteze o eroare și nu ar fi permis ca patch-urile să meargă la Git, dar nu este clar ce ar fi făcut de fapt și cât de departe ar fi putut merge.
Total în august 2020 de la adrese anonime [e-mail protejat] и [e-mail protejat] (scrisoare de la James Bond) au fost trimise cinci patch-uri: două corecte (1, 2) și trei conținând erori ascunse (1, 2, 3), creând condiții pentru vulnerabilități. Fiecare patch conține doar 1-4 linii de cod. Ideea principală din spatele patch-urilor eronate a fost că repararea unei scurgeri de memorie ar putea crea o dublă condiție de vulnerabilitate liberă. O săptămână mai târziu, au fost trimise informații dezvoltatorilor de kernel cu o propunere de a discuta despre posibilitatea promovării vulnerabilităților sub pretextul unor remedieri banale pentru scurgeri de memorie, dar nu s-a spus nimic despre încercările anterioare de a trimite patch-uri rău intenționate.
Primul patch problematic a remediat scurgerea memoriei adăugând un apel la kfree() înainte de a reveni controlul în cazul unei erori, dar a creat condiții pentru accesarea zonei de memorie după ce aceasta a fost eliberată (use-after-free). Acest patch a fost respins de întreținător (Jiri Slaby), care a identificat problema și a subliniat că în urmă cu un an cineva a încercat deja să propună o modificare similară și a fost acceptată inițial, dar apoi a fost eliminată după identificarea condițiilor pentru vulnerabilitate. > p2 = p1[n] = kmalloc_array(64, sizeof(u16), GFP_KERNEL); > - dacă (!p2) returnează -ENOMEM; > + dacă (!p2) { > + kfree(p1); > + return -ENOMEM; > + }
Al doilea plasture conținea, de asemenea, condiții pentru problema de utilizare după ce nu se poate folosi. Patch-ul specificat nu a fost acceptat de întreținător (Dan Carpenter), care a respins patch-ul din cauza unei alte probleme cu list_add_tail, dar nu a observat că pointerul „chdev” ar putea fi eliberat în funcția put_device, care este folosită mai jos în apel. dev_err(&chdev ->dev..). Cu toate acestea, patch-ul nu a fost acceptat, deși din motive care nu au legătură cu vulnerabilitatea. if (ret < 0) { + put_device(&chdev->dev); dev_err(&chdev->dev, DRV_NAME ": kfifo_alloc failed\n"); ret = -ENOMEM; goto err_fifo;
Nici cel de-al treilea patch nu a fost acceptat de întreținător (Miquel Raynal) din cauza unui alt bug care nu are legătură cu vulnerabilitatea (apel dublu de pus pentru pdev). if (!window->virt) { printk(KERN_ERR MOD_NAME ": ioremap(%08lx, %08lx) failed\n", window->phys, window->size); + pci_dev_put(pdev); ieși afară; } ... if (!map) { printk(KERN_ERR MOD_NAME ": kmalloc failed"); + pci_dev_put(pdev); ieși afară; } memset(hartă, 0, dimensiunea(*hartă)); ... if (mtd_device_register(map->mtd, NULL, 0)) { map_destroy(map->mtd); map->mtd = NULL; + pci_dev_put(pdev); ieși afară; }
Interesant, s-a presupus inițial că 4 din 5 patch-uri au avut probleme, dar cercetătorii înșiși au făcut o greșeală și într-un patch care a fost problematic, după părerea lor, a fost propusă o remediere corectă, fără condițiile așteptate pentru utilizarea memoriei după apariția liberă. err = pci_request_mem_regions(pdev, nitrox_driver_name); if (err) { pci_disable_device(pdev); + dev_err(&pdev->dev, „Eșuat la solicitarea regiunilor mem!\n”); întoarce greșeală; }
Sursa: opennet.ru