Миннесотагийн их сургуулийн баг илгээсэн хортой өөрчлөлтүүдийн талаарх дэлгэрэнгүй мэдээллийг илчилсэн байна

Линукс цөмд хийсэн өөрчлөлтийг хүлээн зөвшөөрөхийг Грег Кроа-Хартман хаасан Миннесотагийн их сургуулийн хэсэг судлаачид уучлалт хүссэн нээлттэй захидлын дараа цөмийн хөгжүүлэгчид рүү илгээсэн засварууд болон засварлагч нартай захидал харилцааны талаар дэлгэрэнгүй мэдээллийг илчилсэн байна. эдгээр засваруудтай холбоотой.

Асуудалтай бүх нөхөөсийг засварлагчдын санаачилгаар татгалзсан нь анхаарал татаж байгаа бөгөөд нэг ч засвар батлагдаагүй байна. Энэ баримт нь Грег Кроа-Хартман яагаад ийм хатуу ширүүн үйлдэл хийснийг тодорхой харуулж байна, учир нь засварын ажилчид зөвшөөрөгдсөн бол судлаачид юу хийх байсан нь тодорхойгүй байна. Эргээд харахад тэд алдааны талаар мэдээлэх зорилготой байсан бөгөөд засваруудыг Гит рүү оруулахыг зөвшөөрөхгүй байсан гэж мэдэгдсэн боловч тэд яг юу хийж байсан, хэр хол явсан нь тодорхойгүй байна.

Нийт 2020 оны XNUMX-р сард нэр нь үл мэдэгдэгч хаягаас [имэйлээр хамгаалагдсан] и [имэйлээр хамгаалагдсан] (Жеймс Бондын захидал) таван нөхөөсийг илгээсэн: хоёр нь зөв (1, 2), гурав нь далд алдаа (1, 2, 3) агуулсан бөгөөд эмзэг байдлыг бий болгох нөхцлийг бүрдүүлсэн. Нүхэн бүр ердөө 1-4 мөр код агуулсан байв. Алдаатай засваруудын цаадах гол санаа нь санах ойн алдагдлыг засах нь давхар үнэгүй эмзэг байдлыг бий болгож чадна гэсэн санаа байв. Долоо хоногийн дараа цөмийн хөгжүүлэгчид санах ой алдагдсантай холбоотой өчүүхэн засвар нэрийн дор эмзэг байдлыг дэмжих боломжийг хэлэлцэх саналтай мэдээлэл илгээсэн боловч урьд өмнө нь хортой засвар илгээх оролдлогын талаар юу ч хэлээгүй байна.

Анхны асуудалтай нөхөөс нь алдаа гарсан тохиолдолд хяналтыг буцаахын өмнө kfree() руу залгах замаар санах ойн алдагдлыг зассан боловч санах ойг сулласны дараа (үнэгүй ашигласны дараа) хандах нөхцөлийг бүрдүүлсэн. Энэ нөхөөсийг засварлагч (Жири Слаби) татгалзсан бөгөөд тэр асуудлыг тодорхойлж, нэг жилийн өмнө хэн нэгэн ижил төстэй өөрчлөлтийг санал болгохыг оролдсон бөгөөд үүнийг анх хүлээн зөвшөөрсөн боловч эмзэг байдлын нөхцөлийг тодорхойлсны дараа устгасан гэдгийг онцолсон. > p2 = p1[n] = kmalloc_array(64, sizeof(u16), GFP_KERNEL); > - хэрэв (!p2) буцаана -ENOMEM; > + хэрэв (!p2) { > + kfree(p1); > + буцах -ENOMEM; > + }

Хоёрдахь нөхөөс нь ашиглалтын дараа үнэгүй асуудалтай холбоотой нөхцөлүүдийг агуулна. Заасан нөхөөсийг засварлагч (Дан Карпентер) хүлээн аваагүй бөгөөд list_add_tail-тэй холбоотой өөр асуудлаас болж засвараас татгалзсан боловч "chdev" заагчийг дуудлагад доор ашигласан put_device функцэд чөлөөлж болохыг анзаарсангүй. dev_err(&chdev ->dev...). Гэсэн хэдий ч эмзэг байдалтай холбоогүй шалтгаанаар уг засварыг хүлээж аваагүй. if (ret < 0) { + put_device(&chdev->dev); dev_err(&chdev->dev, DRV_NAME ": kfifo_alloc амжилтгүй болсон\n"); ret = -ENOMEM; err_fifo руу очих;

Гурав дахь засварыг мөн эмзэг байдалтай холбоогүй өөр нэг алдааны улмаас засварчин (Микэл Рэйнал) хүлээн аваагүй (pdev-д давхар дуудлага хийх). if (!window->virt) { printk(KERN_ERR MOD_NAME ": ioremap(%08lx, %08lx) амжилтгүй болсон\n", window->phys, window->size); + pci_dev_put(pdev); гарах; } ... if (!map) { printk(KERN_ERR MOD_NAME ": kmalloc амжилтгүй болсон"); + pci_dev_put(pdev); гарах; } memset(газрын зураг, 0, sizeof(*газрын зураг)); ... хэрэв (mtd_device_register(map->mtd, NULL, 0)) { map_destroy(map->mtd); map->mtd = NULL; + pci_dev_put(pdev); гарах; }

Сонирхолтой нь, 4 нөхөөсийн 5 нь асуудалтай гэж анх таамаглаж байсан ч судлаачид өөрсдөө алдаа гаргаж, нэг нөхөөс нь асуудалтай гэж үзээд, чөлөөт тохиолдсоны дараа санах ойн ашиглалтын хүлээгдэж буй нөхцөлгүйгээр зөв засварыг санал болгосон. алдаа = pci_request_mem_regions(pdev, nitrox_driver_name); хэрэв (алдаа) { pci_disable_device(pdev); + dev_err(&pdev->dev, “Мем бүсүүдийг хүсэх боломжгүй!\n”); буцах алдаа; }

Эх сурвалж: opennet.ru

сэтгэгдэл нэмэх