મિનેસોટા યુનિવર્સિટીની એક ટીમે મોકલવામાં આવેલા દૂષિત ફેરફારો વિશે વિગતો જાહેર કરી છે.

માફીના ખુલ્લા પત્ર પછી, મિનેસોટા યુનિવર્સિટીના સંશોધકોના એક જૂથે કર્નલમાં ફેરફારો સ્વીકાર્યા Linux જેમાંથી ગ્રેગ ક્રોહ-હાર્ટમેને બ્લોક કર્યું હતું, તેમાં કર્નલ ડેવલપર્સને મોકલવામાં આવેલા પેચો અને આ પેચો સંબંધિત જાળવણીકારો સાથેના પત્રવ્યવહાર વિશે વિગતવાર માહિતી જાહેર કરવામાં આવી હતી.

તે નોંધનીય છે કે તમામ સમસ્યારૂપ પેચો જાળવણીકારોની પહેલ પર નકારી કાઢવામાં આવ્યા હતા; એક પણ પેચ મંજૂર કરવામાં આવ્યો ન હતો. આ હકીકત એ સ્પષ્ટ કરે છે કે ગ્રેગ ક્રોહ-હાર્ટમેને શા માટે આટલું કઠોર વર્તન કર્યું, કારણ કે તે સ્પષ્ટ નથી કે જો પેચો જાળવણીકારો દ્વારા મંજૂર કરવામાં આવ્યા હોત તો સંશોધકોએ શું કર્યું હોત. પશ્ચાતદૃષ્ટિમાં, તેઓએ દાવો કર્યો હતો કે તેઓ બગની જાણ કરવાનો ઈરાદો ધરાવતા હતા અને પેચોને ગિટ પર જવા દીધા ન હોત, પરંતુ તે અસ્પષ્ટ છે કે તેઓએ ખરેખર શું કર્યું હશે અને તેઓ કેટલા દૂર ગયા હશે.

કુલ મળીને, ઓગસ્ટ 2020 માં, અનામી એકોસ્ટેગ સરનામાંઓમાંથી.ubuntuપાંચ પેચ @gmail.com અને jameslouisebond@gmail.com પર મોકલવામાં આવ્યા હતા (ઈમેલ જેમ્સ બોન્ડ તરફથી હતો): બે સાચા પેચ (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..). જો કે, પેચ સ્વીકારવામાં આવ્યો ન હતો, જોકે નબળાઈ સાથે અસંબંધિત કારણોસર. જો (ret < 0) { + put_device(&chdev->dev); dev_err(&chdev->dev, DRV_NAME ": kfifo_alloc નિષ્ફળ\n"); ret = -ENOMEM; જાઓ err_fifo;

ત્રીજો પેચ પણ જાળવણીકાર (મિકેલ રેનલ) દ્વારા સ્વીકારવામાં આવ્યો ન હતો કારણ કે નબળાઈ સાથે સંબંધિત નથી (pdev માટે ડબલ કૉલ). જો (!window->virt) { printk(KERN_ERR MOD_NAME": ioremap(%08lx, %08lx) નિષ્ફળ\n", window->phys, window->size); + pci_dev_put(pdev); બહાર જાઓ; } ... જો (!નકશો) { printk(KERN_ERR MOD_NAME ": kmalloc નિષ્ફળ"); + pci_dev_put(pdev); બહાર જાઓ; } મેમસેટ(નકશો, 0, માપનો(*નકશો)); ... જો (mtd_device_register(map->mtd, NULL, 0)) { map_destroy(map->mtd); map->mtd = NULL; + pci_dev_put(pdev); બહાર જાઓ; }

રસપ્રદ વાત એ છે કે, શરૂઆતમાં 4 માંથી 5 પેચમાં સમસ્યા હોવાનું માનવામાં આવતું હતું, પરંતુ સંશોધકોએ પોતે ભૂલ કરી હતી અને એક પેચ જે સમસ્યારૂપ હતી, તેમના મતે, મુક્ત થયા પછી મેમરીના ઉપયોગ માટે અપેક્ષિત શરતો વિના, યોગ્ય સુધારાની દરખાસ્ત કરવામાં આવી હતી. err = pci_request_mem_regions(pdev, nitrox_driver_name); જો (ભૂલ) { pci_disable_device(pdev); + dev_err(&pdev->dev, "મેમ પ્રદેશોની વિનંતી કરવામાં નિષ્ફળ!\n"); વળતર ભૂલ; }

સોર્સ: opennet.ru