在过去的几天里 一组研究人员采取的行动的案例 来自明尼苏达大学，因为从许多角度来看，与在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中的双重应用程序）。