Tijekom posljednjih nekoliko dana slučaj o radnjama koje je poduzela skupina istraživača sa Sveučilišta Minnesota, budući da iz perspektive mnogih, takvi postupci u vezi s uvođenjem ranjivosti u Linux kernel nemaju opravdanja.
I premda grupa Istraživači sa Sveučilišta Minnesotobjaviti otvoreno pismo isprike, čije je prihvaćanje promjena na Linux jezgri koje je blokirao Greg Kroah-Hartman, otkrio detalje zakrpa predanih programerima jezgre i dopisivanje s održavačima povezanim s tim zakrpama.
Značajno je da sve zakrpe problema su odbačene Na inicijativu održavatelja, nijedan zakrpa nije odobrena. Iz ove činjenice je jasno zašto je Greg Kroah-Hartman postupio tako oštro, jer je nejasno što bi istraživači učinili da je zakrpe odobrio održavatelj.
Retrospektivno, tvrdio da namjeravaju prijaviti grešku i ne bi dopustili da zakrpe idu u Git, ali nejasno je što bi zapravo radili ili dokle bi mogli ići.
Ukupno je u kolovozu 2020. s anonimnih adresa acostag.ubuntu@gmail.com i jameslouisebond@gmail.com (pismo Jamesa Bonda) poslano pet zakrpa: dvije ispravne i tri uključujući skrivene pogreške, stvarajući uvjete za pojavu ranjivosti.
Svaka zakrpa sadržavala je samo 1 do 4 retka koda. Glavna ideja iza loših zakrpa bila je da bi popravljanje curenja memorije moglo stvoriti uvjet za dvostruku besplatnu ranjivost.
Cilj projekta je poboljšati sigurnost postupka zakrpe u OSS-u. Kao dio projekta proučavamo potencijalne probleme s postupkom zakrpe OSS-a, uključujući uzroke problema i prijedloge za njihovo rješavanje.
Zapravo, ova studija otkriva neke probleme, ali njezin je cilj pozvati na napore na poboljšanju
postupak zakrpanja kako bi se motiviralo više na rad na razvoju tehnika za testiranje i provjeru zakrpa i na kraju kako bi OS učinio sigurnijim.Na temelju tih zakrpa rezimiramo njihove obrasce, proučavamo specifične razloge zbog kojih je zakrpe za uvođenje grešaka teško uhvatiti (i kvalitativnom i kvantitativnom analizom), i što je najvažnije, dajemo prijedloge za rješavanje problema.
Prva problematična zakrpa popravila je curenje memorije dodavanjem poziva kfree () prije vraćanja kontrole u slučaju pogreške, ali stvaranja uvjeta za pristup memorijskom području nakon što je oslobođeno (bez upotrebe).
Održavač je odbio navedenu zakrpu, koji je identificirao problem i naznačio da je prije godinu dana netko već pokušao predložiti sličnu promjenu i ona je u početku bila prihvaćena, ali je odbačena isti dan nakon identificiranja uvjeta ranjivosti.
Drugi flaster također je sadržavao uvjete za izdanje nakon izdanja. Održavatelj nije prihvatio navedenu zakrpu, odbacivši zakrpu zbog drugog problema s list_add_tail, ali nije primijetio da se pokazivač "chdev" može osloboditi u funkciji put_device, koja se koristi sljedeća u pozivu na dev_err (& chdev -> razv ..). Međutim, zakrpa nije prihvaćena, iako iz razloga koji nisu povezani s ranjivošću.
Znatiželjno, u početku se pretpostavljalo da 4 od 5 zakrpa imaju problema, ali istraživači su sami pogriješili i u problematičnoj zakrpi, prema njihovom mišljenju, predloženo je ispravno rješenje, bez navodnih uvjeta za upotrebu memorije nakon pokretanja.
U ovom radu predstavljamo koncept «nezrele ranjivosti» gdje stanje ranjivosti nedostaje, ali ono može postati stvarno kad stanje
predstavljen zakrpom za drugu grešku.Također razvijamo alate koji nam pomažu pronaći mjesta koda koja mogu patiti
zakrpa za uvođenje programskih pogrešaka i sugerirajte što bi ove zakrpe za uvođenje programskih pogrešaka moglo teško otkriti.Tjedan dana kasnije, programerima jezgre poslane su informacije s prijedlogom da se razgovara o mogućnosti promoviranja ranjivosti pod krinkom trivijalnih popravaka zbog curenja memorije, ali ništa nije rečeno o prethodnim pokušajima podnošenja zlonamjernih zakrpa.
Treću zakrpu također je odbacio održavatelj zbog druge greške bez ranjivosti (dvostruka aplikacija u pdev-u).