Linux çekirdeğinde yapılan değişiklikleri kabul etmesi Greg Croah-Hartman tarafından engellenen Minnesota Üniversitesi'nden bir grup araştırmacı, açık bir özür mektubunun ardından, çekirdek geliştiricilerine gönderilen yamalar ve bakımcılarla yapılan yazışmalar hakkında ayrıntılı bilgi verdi. bu yamalarla ilgili.
Sorunlu yamaların tamamının bakımcıların inisiyatifiyle reddedildiği, tek bir yama bile onaylanmadığı dikkat çekiyor. Bu gerçek, Greg Croah-Hartman'ın neden bu kadar sert davrandığını açıkça ortaya koyuyor; çünkü yamalar geliştiriciler tarafından onaylansaydı araştırmacıların ne yapacağı belli değil. Geriye dönüp bakıldığında, bir hatayı bildirmeyi amaçladıklarını ve yamaların Git'e gitmesine izin vermeyeceklerini iddia ettiler, ancak gerçekte ne yapacakları ve ne kadar ileri gidebilecekleri belli değil.
Ağustos 2020'de anonim adreslerden alınan toplam [e-posta korumalı] и [e-posta korumalı] (James Bond'dan mektup) beş yama gönderildi: ikisi doğru (1, 2) ve üçü gizli hatalar içeriyor (1, 2, 3), güvenlik açıkları için koşullar yaratıyor. Her yama yalnızca 1-4 satır kod içeriyordu. Hatalı yamaların ardındaki ana fikir, bellek sızıntısını düzeltmenin çifte serbest güvenlik açığı durumu yaratabilmesiydi. Bir hafta sonra, çekirdek geliştiricilerine, bellek sızıntılarına yönelik önemsiz düzeltmeler kisvesi altında güvenlik açıklarını artırma olasılığını tartışmak üzere bir öneriyle birlikte bilgi gönderildi, ancak kötü amaçlı yamalar göndermeye yönelik önceki girişimler hakkında hiçbir şey söylenmedi.
İlk sorunlu yama, bir hata durumunda kontrolü geri döndürmeden önce kfree()'ye bir çağrı ekleyerek bellek sızıntısını düzeltti, ancak serbest bırakıldıktan sonra bellek alanına erişim için koşullar yarattı (serbest kullanımdan sonra). Bu yama, sorunu tanımlayan geliştirici (Jiri Slaby) tarafından reddedildi ve bir yıl önce birisinin zaten benzer bir değişiklik önermeye çalıştığını ve başlangıçta kabul edildiğini, ancak daha sonra güvenlik açığının koşullarını belirledikten sonra iptal edildiğini belirtti. > p2 = p1[n] = kmalloc_array(64, sizeof(u16), GFP_KERNEL); > - eğer (!p2) -ENOMEM'i döndürürse; > + if (!p2) { > + kfree(p1); > + dönüş -ENOMEM; > + }
İkinci yama aynı zamanda serbest bırakma sonrası kullanım sorununun koşullarını da içeriyordu. Belirtilen yama, list_add_tail ile ilgili başka bir sorun nedeniyle yamayı reddeden, ancak çağrıda aşağıda kullanılan put_device işlevinde "chdev" işaretçisinin serbest bırakılabileceğini fark etmeyen bakımcı (Dan Carpenter) tarafından kabul edilmedi. dev_err(&chdev ->dev..). Ancak yama, güvenlik açığıyla ilgisi olmayan nedenlerden dolayı kabul edilmedi. if (ret < 0) { + put_device(&chdev->dev); dev_err(&chdev->dev, DRV_NAME ": kfifo_alloc başarısız oldu\n"); ret = -ENOMEM; err_fifo'ya git;
Üçüncü yama da güvenlik açığıyla ilgili olmayan başka bir hata nedeniyle (pdev için çift çağrı) bakımcı (Miquel Raynal) tarafından kabul edilmedi. if (!window->virt) { printk(KERN_ERR MOD_NAME ": ioremap(%08lx, %08lx) başarısız oldu\n", window->phys, window->size); + pci_dev_put(pdev); dışarı çık; } ... if (!map) { printk(KERN_ERR MOD_NAME ": kmalloc başarısız oldu"); + pci_dev_put(pdev); dışarı çık; } memset(harita, 0, sizeof(*harita)); ... if (mtd_device_register(harita->mtd, NULL, 0)) { harita_destroy(harita->mtd); harita->mtd = NULL; + pci_dev_put(pdev); dışarı çık; }
İlginç bir şekilde, başlangıçta 4 yamadan 5'ünün sorunlu olduğu varsayıldı, ancak araştırmacıların kendisi bir hata yaptı ve onlara göre sorunlu olan bir yamada, serbest meydana geldikten sonra bellek kullanımı için beklenen koşullar olmadan doğru bir düzeltme önerildi. hata = pci_request_mem_regions(pdev, nitrox_driver_name); if (hata) { pci_disable_device(pdev); + dev_err(&pdev->dev, “Mem bölgeleri istenemedi!\n”); hataya dönüş; }
Kaynak: opennet.ru