University of Minnesota suspended from Linux kernel development for submitting dubious patches

Greg Kroah-Hartman, who maintains the stable branch of the Linux kernel, has made the decision to prevent any changes coming from the University of Minnesota from being accepted into the Linux kernel, as well as to roll back all previously accepted patches and re-review them. The reason for the blocking was the activity of a research group studying the possibility of promoting hidden vulnerabilities in the code of open projects. The said group submitted patches containing various kinds of bugs, observed the community's reaction, and explored ways to cheat the change review process. According to Greg, conducting such experiments to introduce malicious changes is unacceptable and unethical.

The reason for the block was the sending of a patch by the members of this group, which added a check of the pointer to exclude a possible double call to the “free” function. Given the context in which the pointer was used, the check was pointless. The purpose of submitting the patch was to see if the erroneous change would pass review by the core developers. In addition to the specified patch, other attempts by developers from the University of Minnesota to make dubious changes to the kernel surfaced, including those related to the addition of hidden vulnerabilities.

The participant who sent the patches tried to justify himself by saying that he was testing a new static analyzer and the change was prepared based on the results of the check in it. But Greg drew attention to the fact that the proposed fixes are not typical for bugs detected by static analyzers, and all the patches sent do not fix anything at all. Given that the research group in question has already attempted to push patches with hidden vulnerabilities in the past, it is clear that they have continued their experiments with the kernel development community.

Interestingly, in the past, the leader of the experimenting group was involved in a legitimate fix for vulnerabilities, for example, revealed information leaks in the USB stack (CVE-2016-4482) and the network subsystem (CVE-2016-4485). In a covert promotion study, a group from the University of Minnesota provides an example of a vulnerability CVE-2019-12819 caused by a patch accepted into the kernel in 2014. The fix added a put_device call to the error handling block in mdio_bus, but five years later it surfaced that such manipulation leads to accessing the memory block after it is freed (“use-after-free”).

At the same time, the authors of the study claim that in their work they summarized data on 138 patches that introduce errors and are not related to the study participants. Attempts to send their own patches with errors were limited to email correspondence, and such changes did not get into Git (if after sending the patch by email, the maintainer considered the patch normal, then he was asked not to include the change because there was an error, after which the correct patch was sent).

Addition 1: Judging by the activity of the author of the criticized fix, he has been sending patches to various kernel subsystems for a long time. For example, the radeon and nouveau drivers have recently received changes with a call to pm_runtime_put_autosuspend(dev->dev) in a bug block, possibly causing the buffer to be used after the memory associated with it is freed.

Addendum 2: Greg reverted 190 commits related to "@umn.edu" addresses and initiated a re-review. The problem is that contributors with "@umn.edu" addresses have not only experimented with pushing dubious patches, but also patching real vulnerabilities, and rolling back changes can lead to the return of previously fixed security issues. Some maintainers have already rechecked the reverted changes and found no problems, but one of the maintainers indicated that one of the patches sent to him had errors.

Source: opennet.ru

Add a comment