Etter et åpent unnskyldningsbrev avslørte en gruppe forskere fra University of Minnesota, hvis aksept av endringer i Linux-kjernen ble blokkert av Greg Croah-Hartman, detaljert informasjon om oppdateringene som ble sendt til kjerneutviklerne og korrespondansen med vedlikeholderne relatert til disse lappene.
Det er bemerkelsesverdig at alle de problematiske oppdateringene ble avvist på initiativ fra vedlikeholderne; ikke en eneste oppdatering ble godkjent. Dette faktum gjør det klart hvorfor Greg Croah-Hartman handlet så hardt, siden det er uklart hva forskerne ville ha gjort hvis lappene hadde blitt godkjent av vedlikeholderne. I ettertid hevdet de at de hadde til hensikt å rapportere en feil og ikke ville ha latt patchene gå til Git, men det er uklart hva de faktisk ville ha gjort og hvor langt de kunne ha gått.
Totalt i august 2020 fra anonyme adresser [e-postbeskyttet] и [e-postbeskyttet] (brev fra James Bond) fem patcher ble sendt: to korrekte (1, 2) og tre som inneholdt skjulte feil (1, 2, 3), og skapte forhold for sårbarheter. Hver patch inneholdt bare 1-4 linjer med kode. Hovedideen bak de feilaktige oppdateringene var at å fikse en minnelekkasje kunne skape en dobbel ledig sårbarhetstilstand. En uke senere ble informasjon sendt til kjerneutviklerne med et forslag om å diskutere muligheten for å fremme sårbarheter under dekke av trivielle rettelser for minnelekkasjer, men det ble ikke sagt noe om tidligere forsøk på å sende ondsinnede patcher.
Den første problematiske oppdateringen fikset minnelekkasjen ved å legge til et kall til kfree() før den returnerte kontroll i tilfelle en feil, men skapte betingelser for tilgang til minneområdet etter at det ble frigjort (bruk-etter-fri). Denne oppdateringen ble avvist av vedlikeholderen (Jiri Slaby), som identifiserte problemet og påpekte at for et år siden hadde noen allerede forsøkt å foreslå en lignende endring, og den ble først akseptert, men deretter forkastet etter å ha identifisert betingelsene for sårbarheten. > p2 = p1[n] = kmalloc_array(64, sizeof(u16), GFP_KERNEL); > - hvis (!p2) returnerer -ENOMEM; > + if (!p2) { > + kfree(p1); > + retur -ENOMEM; > + }
Den andre lappen inneholdt også betingelser for bruk etter-fri-problemet. Den angitte oppdateringen ble ikke akseptert av vedlikeholderen (Dan Carpenter), som avviste oppdateringen på grunn av et annet problem med list_add_tail, men la ikke merke til at "chdev"-pekeren kunne frigjøres i put_device-funksjonen, som brukes nedenfor i samtalen dev_err(&chdev ->dev..). Patchen ble imidlertid ikke akseptert, selv om det var grunner som ikke var relatert til sårbarheten. if (ret < 0) { + put_device(&chdev->dev); dev_err(&chdev->dev, DRV_NAME ": kfifo_alloc mislyktes\n"); ret = -ENOMEM; goto err_fifo;
Den tredje oppdateringen ble heller ikke akseptert av vedlikeholderen (Miquel Raynal) på grunn av en annen feil som ikke var relatert til sårbarheten (dobbelt kall å sette for pdev). if (!window->virt) { printk(KERN_ERR MOD_NAME ": ioremap(%08lx, %08lx) mislyktes\n", window->phys, window->størrelse); + pci_dev_put(pdev); gå ut; } ... if (!map) { printk(KERN_ERR MOD_NAME ": kmalloc mislyktes"); + pci_dev_put(pdev); gå ut; } memset(kart, 0, størrelse på(*kart)); ... if (mtd_device_register(map->mtd, NULL, 0)) { map_destroy(map->mtd); map->mtd = NULL; + pci_dev_put(pdev); gå ut; }
Interessant nok ble 4 av 5 patcher i utgangspunktet antatt å ha problemer, men forskerne gjorde selv en feil og i en patch som var problematisk ble det etter deres mening foreslått en korrekt fiksering, uten at de forventede betingelsene for minnebruk etter fri oppstod. feil = pci_request_mem_regions(pdev, nitrox_driver_name); if (feil) { pci_disable_device(pdev); + dev_err(&pdev->dev, “Kunne ikke be om medlemsregioner!\n”); returnere feil; }
Kilde: opennet.ru