Greg Kroah-Hartman, who is responsible for maintaining the stable branch of the Linux kernel made it known I've been drinking for several days the decision to deny any changes from the University of Minnesota to the Linux kernel, and revert all previously accepted patches and recheck them.
The reason for the blockade was the activities of a research group that studies the possibility of promoting hidden vulnerabilities in the code of open source projects, since this group has sent patches that include errors of various types.
Given the context of using the pointer, it made no sense and the purpose of the patch submission was to investigate whether the erroneous change would pass the kernel developers' review.
In addition to this patch, There have been other attempts by developers at the University of Minnesota to make questionable changes to the kernel, including those related to adding hidden vulnerabilities.
The contributor who sent the patches tried to justify himself testing a new static analyzer and the change was prepared based on the test results on it.
However Greg drew attention to the fact that the proposed corrections are not typical of errors detected by static analyzers, and the patches sent do not solve anything. Since the group of researchers in question have already tried in the past to introduce solutions with hidden vulnerabilities, it is clear that they have continued their experiments in the kernel development community.
Interestingly, in the past, the leader of the experimentation group has been involved in fixes for legitimate vulnerabilities, such as information leakage on the USB stack (CVE-2016-4482) and networks (CVE-2016-4485).
In a study of hidden vulnerability propagation, the University of Minnesota team cites an example of the CVE-2019-12819 vulnerability, caused by a patch that was accepted into the kernel in 2014. The solution added a put_device call to the block of error handling in mdio_bus, but five years later it was revealed that such manipulation would result in use-after-free access to the memory block.
At the same time, the study authors claim that in their work they summarized data on 138 patches that introduce errors, but are not related to the study participants.
Attempts to submit your own bug patches were limited to mail correspondence and such changes did not reach the Git commit stage in any kernel branch (if after emailing the patch the maintainer found the patch to be normal, then you were asked not to include the change because there is a error, after which the correct patch was shipped).
Also, judging from the activity of the author of the criticized fix, he has been pushing patches to various kernel subsystems for a long time. For example radeon and nouveau drivers recently adopted changes to pm_runtime_put_autosuspend (dev-> dev) block errors, it may lead to the use of a buffer after releasing associated memory.
It is also mentioned that Greg rolled back 190 associated commits and started a new review. The problem is that @ umn.edu contributors not only experimented with promoting questionable patches, they also fixed actual vulnerabilities, and rolling back the changes could lead to the return of previously fixed security issues. Some maintainers have already rechecked the unmade changes and found no problems, but there were also bug patches.
The Department of Computer Science at the University of Minnesota issued a statement announcing the suspension of the investigation in this area, initiating the validation of the methods used and conducting an investigation on how this investigation was approved. The results report will be shared with the community.
Finally Greg mentions that he has observed the responses from the community and also taking into account the process of exploring ways to cheat the review process. In Greg's opinion, conducting such experiments to introduce harmful changes is unacceptable and unethical.
Source: https://lkml.org