मिनेसोटा विश्वविद्यालय की एक टीम ने भेजे गए दुर्भावनापूर्ण परिवर्तनों के बारे में विवरण प्रकट किया है।

माफ़ी के एक खुले पत्र के बाद, मिनेसोटा विश्वविद्यालय के शोधकर्ताओं का एक समूह, जिनकी लिनक्स कर्नेल में परिवर्तनों की स्वीकृति ग्रेग क्रोह-हार्टमैन द्वारा अवरुद्ध कर दी गई थी, ने कर्नेल डेवलपर्स को भेजे गए पैच और अनुरक्षकों के साथ पत्राचार के बारे में विस्तृत जानकारी का खुलासा किया। इन पैच से संबंधित.

यह उल्लेखनीय है कि सभी समस्याग्रस्त पैच को अनुरक्षकों की पहल पर अस्वीकार कर दिया गया था; एक भी पैच को मंजूरी नहीं दी गई थी। यह तथ्य यह स्पष्ट करता है कि ग्रेग क्रोह-हार्टमैन ने इतना कठोर व्यवहार क्यों किया, क्योंकि यह स्पष्ट नहीं है कि यदि पैच को रखरखावकर्ताओं द्वारा अनुमोदित किया गया होता तो शोधकर्ताओं ने क्या किया होता। अंत में, उन्होंने दावा किया कि उनका इरादा एक बग की रिपोर्ट करने का था और उन्होंने पैच को Git में जाने की अनुमति नहीं दी होगी, लेकिन यह स्पष्ट नहीं है कि उन्होंने वास्तव में क्या किया होगा और वे कितनी दूर तक गए होंगे।

अगस्त 2020 में कुल अज्ञात पते से [ईमेल संरक्षित] и [ईमेल संरक्षित] (जेम्स बॉन्ड का पत्र) पांच पैच भेजे गए: दो सही (1, 2) और तीन में छिपी हुई त्रुटियां (1, 2, 3), जिससे कमजोरियों की स्थिति पैदा हुई। प्रत्येक पैच में कोड की केवल 1-4 पंक्तियाँ थीं। ग़लत पैच के पीछे मुख्य विचार यह था कि मेमोरी लीक को ठीक करने से दोहरी मुक्त भेद्यता की स्थिति पैदा हो सकती है। एक सप्ताह बाद, मेमोरी लीक के लिए तुच्छ सुधारों की आड़ में कमजोरियों को बढ़ावा देने की संभावना पर चर्चा करने के प्रस्ताव के साथ कर्नेल डेवलपर्स को जानकारी भेजी गई थी, लेकिन दुर्भावनापूर्ण पैच भेजने के पिछले प्रयासों के बारे में कुछ नहीं कहा गया था।

पहले समस्याग्रस्त पैच ने त्रुटि के मामले में नियंत्रण वापस करने से पहले kfree() पर कॉल जोड़कर मेमोरी लीक को ठीक किया, लेकिन मेमोरी क्षेत्र को मुक्त होने के बाद एक्सेस करने के लिए स्थितियां बनाईं (उपयोग-बाद-मुक्त)। इस पैच को अनुरक्षक (जिरी स्लैबी) ने अस्वीकार कर दिया था, जिन्होंने समस्या की पहचान की और बताया कि एक साल पहले किसी ने इसी तरह के बदलाव का प्रस्ताव देने की कोशिश की थी और इसे शुरू में स्वीकार कर लिया गया था, लेकिन फिर भेद्यता की स्थितियों की पहचान करने के बाद इसे छोड़ दिया गया। > p2 = p1[n] = kmalloc_array(64, sizeof(u16), GFP_KERNEL); > - यदि (!p2) वापसी -ENOMEM; > + यदि (!पी2) { > + केफ्री(पी1); > + वापसी -ENOMEM; > + }

दूसरे पैच में उपयोग के बाद-मुक्त समस्या की शर्तें भी शामिल थीं। निर्दिष्ट पैच को अनुरक्षक (डैन कारपेंटर) द्वारा स्वीकार नहीं किया गया था, जिन्होंने list_add_tail के साथ एक अन्य समस्या के कारण पैच को अस्वीकार कर दिया था, लेकिन इस बात पर ध्यान नहीं दिया कि "chdev" पॉइंटर को put_device फ़ंक्शन में मुक्त किया जा सकता है, जिसका उपयोग नीचे कॉल में किया गया है dev_err(&chdev ->dev..). हालाँकि, भेद्यता से असंबंधित कारणों से पैच को स्वीकार नहीं किया गया था। यदि (ret 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); मानचित्र->mtd = शून्य; + 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