V zadnjih dneh je o ukrepih skupine raziskovalcev z univerze v Minnesoti, saj z vidika mnogih takšna dejanja v zvezi z uvedbo ranljivosti v jedru Linuxa nimajo nobene utemeljitve.
Pa čeprav skupina Raziskovalci Univerze v Minnesotuobjaviti odprto pismo opravičila, katerega sprejemanje sprememb v jedru Linuxa, ki ga je blokiral Greg Kroah-Hartman, razkril podrobnosti popravkov, predloženih razvijalcem jedra, in dopisovanje z vzdrževalci, povezanimi s temi popravki.
Omeniti velja, da vsi problemi so bili zavrnjeni Na pobudo vzdrževalcev ni bil odobren noben popravek. To dejstvo jasno kaže, zakaj je Greg Kroah-Hartman ravnal tako ostro, saj ni jasno, kaj bi naredili raziskovalci, če bi popravke odobril vzdrževalec.
Gledajoč nazaj, trdili, da nameravajo prijaviti napako in ne bi dovolili, da bi obliži šli v Git, vendar ni jasno, kaj bi dejansko storili ali kako daleč bi lahko šli.
Avgusta 2020 je bilo z anonimnih naslovov acostag.ubuntu@gmail.com in jameslouisebond@gmail.com (pismo Jamesa Bonda) poslanih pet popravkov: dva pravilna in tri, vključno s skritimi napakami, ki ustvarjajo pogoje za pojav ranljivosti.
Vsak popravek je vseboval le 1 do 4 vrstice kode. Glavna ideja slabih popravkov je bila, da bi odprava puščanja pomnilnika lahko ustvarila pogoj za dvojno brezplačno ranljivost.
Cilj projekta je izboljšati varnost postopka popravljanja v OSS. V okviru projekta preučujemo potencialne težave s postopkom popravljanja OSS, vključno z vzroki težav in predlogi za njihovo odpravljanje.
Dejansko ta študija razkriva nekatere težave, njen cilj pa je pozvati k prizadevanjem za izboljšanje
postopek popravljanja, da se motivira več dela za razvijanje tehnik za testiranje in preverjanje popravkov in na koncu za povečanje varnosti operacijskega sistema.Na podlagi teh popravkov povzamemo njihove vzorce, preučimo posebne razloge, zakaj je popravke za uvedbo hroščev težko ujeti (tako s kvalitativno kot s kvantitativno analizo), in kar je najpomembneje, predlagamo rešitve problema.
Prvi problematični popravek je odpravil uhajanje pomnilnika z dodajanjem klica kfree () preden vrne nadzor v primeru napake, vendar ustvari pogoje za dostop do pomnilniškega območja po sprostitvi (brez uporabe).
Navedeni popravek je vzdrževalec zavrnil, ki je ugotovil težavo in navedel, da je že pred letom dni nekdo poskušal predlagati podobno spremembo, ki je bila sprva sprejeta, vendar je bil isti dan po opredelitvi pogojev ranljivosti zavržen.
Drugi obliž je vseboval tudi pogoje za izdajo po izdaji. Vzdrževalec navedenega popravka ni sprejel, zato je popravek zavrnil zaradi druge težave s list_add_tail, vendar ni opazil, da se lahko kazalec "chdev" sprosti v funkciji put_device, ki se uporablja naslednji v klicu dev_err (& chdev -> razv ..). Vendar popravek ni bil sprejet, čeprav iz razlogov, ki niso povezani z ranljivostjo.
Nenavadno, sprva se je domnevalo, da imajo težave 4 od petih popravkov, vendar so se raziskovalci sami zmotili in v problematičnem popravku je bila po njihovem mnenju predlagana pravilna rešitev, brez domnevnih pogojev za uporabo pomnilnika po zagonu.
V tem delu predstavljamo koncept "nezrele ranljivosti", kjer stanje ranljivosti ni, lahko pa postane resnično, ko je stanje implicitno
uvedel obliž za drugo napako.Razvijamo tudi orodja, ki nam pomagajo najti mesta s kodo, ki bi lahko trpela
popravkov za uvedbo napak in predlagajte, kaj bi lahko otežilo odkrivanje teh odprav.Teden dni kasneje so razvijalcem jedra poslali informacije s predlogom, da bi razpravljali o možnosti promocije ranljivosti pod krinko trivialnih popravkov zaradi uhajanja pomnilnika, vendar o prejšnjih poskusih predložitve zlonamernih popravkov ni bilo nič povedano.
Tretji popravek je vzdrževalec zavrnil tudi zaradi druge napake brez ranljivosti (dvojna aplikacija v pdev).