W następstwie otwartego listu z przeprosinami grupa badaczy z University of Minnesota, której akceptację zmian w jądrze Linuksa zablokował Greg Croah-Hartman, ujawniła szczegółowe informacje na temat poprawek przesłanych twórcom jądra oraz korespondencji z opiekunami związane z tymi poprawkami.
Warto zauważyć, że wszystkie problematyczne łatki zostały odrzucone z inicjatywy opiekunów; ani jedna łatka nie została zatwierdzona. Fakt ten wyjaśnia, dlaczego Greg Croah-Hartman postąpił tak surowo, ponieważ nie jest jasne, co zrobiliby badacze, gdyby łatki zostały zatwierdzone przez opiekunów. Z perspektywy czasu stwierdzili, że zamierzali zgłosić błąd i nie pozwoliliby, aby łatki trafiły do Gita, ale nie jest jasne, co tak naprawdę by zrobili i jak daleko mogli dojść.
Razem w sierpniu 2020 r. z anonimowych adresów [email chroniony] и [email chroniony] (list od Jamesa Bonda) wysłano pięć łat: dwie poprawne (1, 2) i trzy zawierające ukryte błędy (1, 2, 3), tworzące warunki dla podatności. Każda łatka zawierała tylko 1-4 linie kodu. Główną ideą błędnych łat było to, że naprawienie wycieku pamięci może stworzyć podwójną wolną lukę. Tydzień później do twórców jądra wysłano informację z propozycją omówienia możliwości promowania luk pod przykrywką trywialnych poprawek na wycieki pamięci, jednak nic nie powiedziano o wcześniejszych próbach wysyłania szkodliwych łat.
Pierwsza problematyczna łatka naprawiała wyciek pamięci, dodając wywołanie kfree() przed oddaniem kontroli w przypadku błędu, ale stworzyła warunki dostępu do obszaru pamięci po jego zwolnieniu (użyj po zwolnieniu). Łatka ta została odrzucona przez opiekuna (Jiri Slaby), który zidentyfikował problem i wskazał, że rok temu ktoś już próbował zaproponować podobną zmianę i początkowo została ona zaakceptowana, ale następnie odrzucona po zidentyfikowaniu warunków wystąpienia luki. > p2 = p1[n] = kmalloc_array(64, sizeof(u16), GFP_KERNEL); > - jeśli (!p2) zwróć -ENOMEM; > + if (!p2) { > + kfree(p1); > + powrót -ENOMEM; > + }
Druga łatka zawierała również warunki dotyczące problemu użycia po bezpłatnym. Podana łatka nie została zaakceptowana przez opiekuna (Dan Carpenter), który odrzucił łatkę z powodu innego problemu z list_add_tail, ale nie zauważył, że wskaźnik „chdev” mógł zostać zwolniony w funkcji put_device, która jest używana poniżej w wywołaniu dev_err(&chdev ->dev..). Łatka nie została jednak zaakceptowana, choć z powodów niezwiązanych z luką. if (ret < 0) { + put_device(&chdev->dev); dev_err(&chdev->dev, DRV_NAME ": kfifo_alloc nie powiodło się\n"); ret = -ENOMEM; muszę popełnić błąd_fifo;
Trzecia łatka również nie została zaakceptowana przez opiekuna (Miquel Raynal) ze względu na inny błąd niezwiązany z luką (podwójne wywołanie put for pdev). if (!window->virt) { printk(KERN_ERR MOD_NAME ": ioremap(%08lx, %08lx) nie powiodło się\n", okno->phys, okno->rozmiar); + pci_dev_put(pdev); wyjść; } ... if (!map) { printk(KERN_ERR MOD_NAME ": kmalloc nie powiodło się"); + pci_dev_put(pdev); wyjść; } memset(mapa, 0, rozmiar(*mapa)); ... if (mtd_device_register(map->mtd, NULL, 0)) { map_destroy(map->mtd); mapa->mtd = NULL; + pci_dev_put(pdev); wyjść; }
Co ciekawe, początkowo założono, że 4 z 5 łat ma problemy, ale sami badacze popełnili błąd i w jednej łatce, która ich zdaniem była problematyczna, zaproponowano poprawną poprawkę, bez oczekiwanych warunków użycia pamięci po wystąpieniu wolnego. err = pci_request_mem_regions(pdev, nazwa_sterownika nitroxu); if (err) { pci_disable_device(pdev); + dev_err(&pdev->dev, „Nie udało się zażądać regionów pamięci!\n”); zwróć błąd; }
Źródło: opennet.ru