Током последњих неколико дана случај о радњама које је предузела група истраживача са Универзитета у Минесоти, будући да из перспективе многих, такве акције у вези са увођењем рањивости у Линук кернел немају оправдање.
И то иако група Истраживачи са Универзитета у Минесотуобјавити отворено писмо извињења, чије је прихватање промена на Линук језгру које је блокирао Грег Кроах-Хартман открио детаље закрпа предатих програмерима језгра и преписка са одржавачима повезаним са овим закрпама.
Значајно је то све закрпе проблема су одбачене На иницијативу одржавача, ниједан од закрпа није одобрен. Ова чињеница јасно показује зашто се Грег Кроах-Хартман понашао тако оштро, јер је нејасно шта би истраживачи урадили да је закрпе одобрио одржавач.
У ретроспективи, тврдио да намеравају да пријаве грешку и не би дозволили да закрпе иду у Гит, али је нејасно шта би заправо радили или докле би могли да иду.
Укупно је у августу 2020. послато пет закрпа са анонимних адреса ацостаг.убунту@гмаил.цом и јамеслоуисебонд@гмаил.цом (писмо Јамеса Бонда): две тачне и три укључујући скривене грешке, стварајући услове за појаву рањивости.
Свака закрпа садржала је само 1 до 4 реда кода. Главна идеја иза лоших закрпа била је да би поправљање цурења меморије могло створити услов за двоструку бесплатну рањивост.
Пројекат има за циљ побољшање сигурности процеса закрпе у ОСС-у. Као део пројекта проучавамо потенцијалне проблеме са поступком закрпе ОСС-а, укључујући узроке проблема и предлоге за њихово решавање.
Заправо, ова студија открива неке проблеме, али њен циљ је да позове на напоре на побољшању
процес закрпе како би се мотивисао већи рад на развоју техника за тестирање и верификацију закрпа и на крају да би се ОС учинио сигурнијим.На основу ових закрпа, резимирамо њихове обрасце, проучавамо специфичне разлоге због којих је закрпе увођења грешака тешко ухватити (и квалитативном и квантитативном анализом) и најважније дајемо сугестије за решавање проблема.
Прва проблематична закрпа је поправила цурење меморије додавањем позива кфрее () пре враћања контроле у случају грешке, али стварања услова за приступ меморијској области након што је ослобођена (усе-афтер-фрее).
Одржавач је одбио наведену закрпу, који је идентификовао проблем и назначио да је пре годину дана неко већ покушао да предложи сличну промену и она је у почетку била прихваћена, али је одбачена истог дана након идентификације услова рањивости.
Друга закрпа је такође садржала услове за издање након издања. Одржавач није прихватио наведену закрпу, одбацивши закрпу због другог проблема са лист_адд_таил, али није приметио да се показивач "цхдев" може ослободити у функцији пут_девице, која се користи следећа у позиву на дев_ерр (& цхдев -> разв ..). Међутим, закрпа није прихваћена, иако из разлога који нису повезани са рањивошћу.
Знатижељно, у почетку се претпостављало да 4 од 5 закрпа имају проблема, али су сами истраживачи погрешили и у проблематичној закрпи, по њиховом мишљењу, предложено је тачно решење, без претпостављених услова за коришћење меморије након лансирања.
У овом раду представљамо концепт «незреле рањивости» где стање рањивости недостаје, али може постати стварно када је услов имплицитно
представљен закрпом за другу грешку.Такође развијамо алате који нам помажу да пронађемо места са кодом која могу патити
закрпа за увођење грешака и предложите шта би могло учинити ове закрпе за увођење грешака тешким за откривање.Недељу дана касније, програмери језгра су послати информације са предлогом да се разговара о могућности промовисања рањивости под маском тривијалних исправки због цурења меморије, али ништа није речено о претходним покушајима слања злонамерних закрпа.
Трећу закрпу је такође одбио одржавач због друге грешке без рањивости (двострука апликација у пдев-у).