Tokom posljednjih nekoliko dana slučaj o radnjama koje je poduzela grupa istraživača sa Univerziteta u Minnesoti, budući da iz perspektive mnogih, takve akcije u vezi s uvođenjem ranjivosti u Linux kernel nemaju opravdanje.
I to iako grupa Istraživači sa Univerziteta u Minnesotuobjaviti otvoreno pismo izvinjenja, čije je prihvaćanje promjena na Linux jezgri koje je blokirao Greg Kroah-Hartman, otkrio detalje zakrpa predanih programerima jezgre i prepiska s održavačima povezanim s tim zakrpama.
Značajno je to sve zakrpe problema su odbačene Na inicijativu održavatelja, nijedan zakrpa nije odobrena. Ova činjenica jasno pokazuje zašto se Greg Kroah-Hartman ponašao tako oštro, jer je nejasno šta bi istraživači učinili da je zakrpe odobrio održavač.
U retrospektivi, tvrdio je da su namjeravali 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 greš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 procesa zakrpanja 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 njen cilj je pozvati na napore na poboljšanju
proces zakrpe kako bi motivirao više rada na razvoju tehnika za testiranje i provjeru zakrpa i na kraju kako bi OS učinio sigurnijim.Na osnovu ovih 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 greške, ali stvaranja uvjeta za pristup memorijskom području nakon što je oslobođena (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 istog dana nakon identificiranja uvjeta ranjivosti.
Drugi flaster takođe je sadržavao uslove za izdanje nakon izdanja. Održavač nije prihvatio navedenu zakrpu, odbacivši zakrpu zbog drugog problema sa 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 -> razvoj ..). Međutim, zakrpa nije prihvaćena, iako iz razloga koji nisu povezani sa ranjivošću.
Zanimljivo, 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 pretpostavljenih uvjeta za korištenje memorije nakon pokretanja.
U ovom radu predstavljamo koncept «nezrele ranjivosti» gdje stanje ranjivosti nedostaje, ali ono može postati stvarno kada se stanje
predstavljen zakrpom za drugu grešku.Takođe razvijamo alate koji nam pomažu pronaći mjesta koja mogu patiti od koda
zakrpa za uvođenje grešaka i predložite što bi moglo učiniti ove zakrpe za uvođenje grešaka teškim za otkrivanje.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 slanja zlonamernih zakrpa.
Treću zakrpu je takođe odbio održavač zbog druge greške bez ranjivosti (dvostruka aplikacija u pdev-u).