Nakon otvorenog pisma izvinjenja, grupa istraživača sa Univerziteta Minnesota, čije je prihvatanje promjena na Linux kernelu blokirao Greg Croah-Hartman, otkrila je detaljne informacije o zakrpama koje su poslate programerima kernela i prepisku s održavaocima vezano za ove zakrpe.
Važno je napomenuti da su sve problematične zakrpe odbijene na inicijativu održavatelja, niti jedna zakrpa nije odobrena. Ova činjenica jasno daje do znanja zašto je Greg Croah-Hartman postupio tako oštro, budući da je nejasno šta bi istraživači uradili da su zakrpe odobrili održavaoci. Gledajući unazad, tvrdili su da su namjeravali prijaviti grešku i ne bi dozvolili da zakrpe odu u Git, ali je nejasno šta bi zapravo uradili i koliko daleko su mogli otići.
Ukupno u avgustu 2020. sa anonimnih adresa [email zaštićen] и [email zaštićen] (pismo Jamesa Bonda) poslato je pet zakrpa: dvije ispravne (1, 2) i tri koje sadrže skrivene greške (1, 2, 3), stvarajući uslove za ranjivosti. Svaka zakrpa je sadržavala samo 1-4 reda koda. Glavna ideja iza pogrešnih zakrpa bila je da ispravljanje curenja memorije može stvoriti dvostruko stanje slobodnog ranjivosti. Nedelju dana kasnije, informacije su poslate programerima kernela sa predlogom da se razgovara o mogućnosti promovisanja ranjivosti pod krinkom trivijalnih popravki za curenje memorije, ali ništa nije rečeno o prethodnim pokušajima slanja zlonamernih zakrpa.
Prva problematična zakrpa je popravila curenje memorije dodavanjem poziva kfree() prije vraćanja kontrole u slučaju greške, ali je stvorila uvjete za pristup memorijskom području nakon što je oslobođeno (use-after-free). Ovu zakrpu je odbio održavač (Jiri Slaby), koji je identifikovao problem i istakao da je neko pre godinu dana već pokušao da predloži sličnu promenu i da je u početku prihvaćena, ali je potom odbačena nakon identifikovanja uslova za ranjivost. > p2 = p1[n] = kmalloc_array(64, sizeof(u16), GFP_KERNEL); > - ako (!p2) vrati -ENOMEM; > + if (!p2) { > + kfree(p1); > + povratak -ENOMEM; > + }
Druga zakrpa je takođe sadržavala uslove za problem bez upotrebe. Navedenu zakrpu nije prihvatio održavač (Dan Carpenter), koji je odbio zakrpu zbog drugog problema sa list_add_tail, ali nije primijetio da bi se "chdev" pokazivač mogao osloboditi u funkciji put_device, koja se koristi u nastavku u pozivu dev_err(&chdev ->dev..). Međutim, zakrpa nije prihvaćena, iako iz razloga koji nisu vezani za ranjivost. if (ret < 0) { + put_device(&chdev->dev); dev_err(&chdev->dev, DRV_NAME ": kfifo_alloc nije uspio\n"); ret = -ENOMEM; goto err_fifo;
Treću zakrpu također nije prihvatio održavatelj (Miquel Raynal) zbog još jedne greške koja nije povezana sa ranjivosti (dvostruki poziv na put za pdev). if (!window->virt) { printk(KERN_ERR MOD_NAME ": ioremap(%08lx, %08lx) nije uspio\n", window->phys, window->size); + pci_dev_put(pdev); goto out; } ... if (!map) { printk(KERN_ERR MOD_NAME ": kmalloc nije uspio"); + pci_dev_put(pdev); goto out; } memset(map, 0, sizeof(*map)); ... if (mtd_device_register(map->mtd, NULL, 0)) { map_destroy(map->mtd); map->mtd = NULL; + pci_dev_put(pdev); goto out; }
Zanimljivo je da se u početku pretpostavljalo da 4 od 5 zakrpa ima problema, ali su sami istraživači napravili grešku i u jednoj zakrpi koja je bila problematična, po njihovom mišljenju, predložena je ispravna popravka, bez očekivanih uslova za korištenje memorije nakon slobodnog javljanja. err = pci_request_mem_regions(pdev, nitrox_driver_name); if (err) { pci_disable_device(pdev); + dev_err(&pdev->dev, “Zahtjev za mem regije nije uspio!\n”); return err; }
izvor: opennet.ru