在過去的幾天裡 一組研究人員採取的行動的案例 來自明尼蘇達大學，因為從許多角度來看，與在Linux內核中引入漏洞有關的此類行動沒有道理。
即使一群 明尼蘇達大學研究人員發表公開道歉信， 誰接受被Linux阻止的對Linux內核的更改 格雷格·克魯亞·哈特曼（Greg Kroah-Hartman）透露了細節 提交給內核開發人員的補丁的數量以及與這些補丁相關的維護者的對應關係。
值得注意的是 所有問題補丁均被拒絕 在維護者的倡議下，沒有補丁得到批准。 這個事實清楚地說明了為什麼Greg Kroah-Hartman如此嚴厲地採取行動，因為不清楚如果維護者批准了補丁，研究人員將採取什麼行動。
回想起來， 認為他們打算報告該錯誤 並且他們不允許補丁發佈到Git，但是目前尚不清楚它們將實際執行什麼操作或可以執行多遠。
到2020年XNUMX月，總共從匿名地址acostag.ubuntu@gmail.com和jameslouisebond@gmail.com（詹姆斯·邦德的一封信）發送了五個補丁：兩個正確，三個包含隱藏錯誤，為外觀的出現創造了條件。漏洞。
每個補丁僅包含1至4行代碼。 錯誤補丁背後的主要思想是修復內存洩漏可能會為雙重釋放漏洞創造條件。
該項目旨在提高OSS中修補過程的安全性。 作為項目的一部分，我們研究OSS修補過程中的潛在問題，包括問題的原因和解決方案。
實際上，這項研究揭示了一些問題，但其目的是呼籲人們努力改善這種情況。
修補程序，以激發更多的工作來開發測試和驗證修補程序的技術，並最終使操作系統更安全。基於這些補丁，我們總結了它們的模式，研究了難以捕獲錯誤引入補丁的具體原因（通過定性和定量分析），最重要的是，提供了解決問題的建議。
第一個有問題的補丁通過添加對kfree（）的調用來修復內存洩漏 在出現錯誤的情況下返回控制之前，但在釋放存儲區（先使用後釋放）之後創建條件以訪問存儲區。
指定的補丁被維護者拒絕，他發現了問題，並表示一年前有人曾嘗試提出類似的更改，並且最初接受了該更改，但在確定漏洞狀況後的第二天就將其丟棄。
第二個補丁還包含發布後磨損問題的條件。 指定的補丁程序未被維護者接受，維護者由於list_add_tail的另一個問題而拒絕了該補丁程序，但沒有註意到可以在put_device函數中釋放“ chdev”指針，該函數隨後將在調用dev_err（＆ chdev-> dev ..）。 但是，儘管出於與漏洞無關的原因，補丁仍未被接受。
奇怪的是 最初，假設4個補丁中有5個有問題， 但是研究人員自己犯了一個錯誤，並在一個有問題的補丁中提出了正確的解決方案，而沒有啟動後使用內存的假定條件。
在這項工作中，我們提出了“未成熟的脆弱性”的概念，其中缺少脆弱性的條件，但是當脆弱性的條件是
由補丁引入的另一個錯誤。我們還開發了一些工具，可幫助我們找到可能遭受影響的代碼位置
錯誤介紹補丁，並提出可能導致這些錯誤介紹補丁難以檢測的原因。一周後，信息被發送給內核開發人員，並提出了討論，以微不足道的修復方式洩漏內存漏洞來提升漏洞的可能性，但是對於先前提交惡意補丁的嘗試卻絲毫沒有提及。
第三個補丁也被維護者拒絕，因為另一個沒有漏洞的錯誤（pdev中的雙重應用程序）。