Linux Bans University Of Minnesota For Committing Malicious Code
In a rare, groundbreaking decision, Linux kernel project maintainers have imposed a ban on the University of Minnesota (UMN) from contributing to the open-source Linux project.
The move comes after a group of UMN researchers were caught submitting a series of malicious code commits, or patches that deliberately introduced security vulnerabilities in the official Linux codebase, as a part of their research activities.
Additionally, the Linux kernel project maintainers have decided to revert any and all code commits that were ever submitted from an @umn.edu email addresses.
Malicious commits mass-reverted, UMN researchers banned
Today, a major Linux kernel developer, Greg Kroah-Hartman has banned the University of Minnesota (UMN) from contributing to the open-source Linux kernel project.
Kroah-Hartman also decided to revert all commits submitted from any UMN email address thus far.
The developer’s justification for taking this step is:
“Commits from @umn.edu addresses have been found to be submitted in ‘bad faith’ to try to test the kernel community’s ability to review ‘known malicious’ changes.”
“Because of this, all submissions from this group must be reverted from the kernel tree and will need to be re-reviewed again to determine if they actually are a valid fix.”
“Until that work is complete, [we are removing] this change to ensure that no problems are being introduced into the codebase,” said Kroah-Hartman in a series of published emails.
In February 2021, UMN researchers published a research paper titled, “Open Source Insecurity: Stealthily Introducing Vulnerabilities via Hypocrite Commits.”
The focus of this research was to deliberately introduce known security vulnerabilities in the Linux kernel, by submitting malicious or insecure code patches.
As seen by BleepingComputer, the researchers demonstrate many examples of instances where they introduced known vulnerabilities by making these “hypocrite” patch commits:
“Introducing the nullified state is straightforward. The patch is seemingly valid because it nullifies pf->disk->queue after the pointer is released.”
“However, some functions such as pf_detect() and pf_exit() are called after this nullification and they would further dereference this pointer without checking its state, leading to NULL-pointer,” state UMN researchers in their paper.
As seen by BleepingComputer, there are hundreds of commits touting themselves to be “patches” that have been reverted as a part of this process:
UMN Researchers call the accusations “slander”
Soon enough, researcher Aditya Pakki from UMN pushed back asking Kroah-Hartman to refrain “from making wild accusations that are bordering on slander.”
I respectfully ask you to cease and desist from making wild accusations that are bordering on slander.
These patches were sent as part of a new static analyzer that I wrote and it’s sensitivity is obviously not great. I sent patches on the hopes to get feedback. We are not experts in the linux kernel and repeatedly making these statements is disgusting to hear.
Obviously, it is a wrong step but your preconceived biases are so strong that you make allegations without merit nor give us any benefit of doubt. I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts.
To which Kroah-Hartman responded that the Linux kernel developer community does not appreciate being experimented on in this manner.
“If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here,” said Kroah-Hartman.
“Because of this, I will now have to ban all future contributions from your University and rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems,” he continued.
Last year, UMN researchers had compiled a detailed FAQ document in which they stated that the goal of this research was to improve the security of the patching process in open-source software by demonstrating the practicality of bug-introducing patches.
The researchers also stated that any patch suggestions were made via email exchanges and never made it into any code branch, or the Linux kernel.
According to the document, the University’s IRB determined that this was not human research or ethically harmful, and as such cleared the research activities.
Although, the researchers did offer their sincere apologies to Linux maintainers for the time wasted on reviewing “hypocrite” patches:
“We would like to sincerely apologize to the maintainers involved in the corresponding patch review process; this work indeed wasted their precious time.”
“We had carefully considered this issue, but could not figure out a better solution in this study,” state the researchers.
Brad Spengler, President of Open Source Security Inc. weighed in on the matter, calling this an “overreaction” on the Linux kernel maintainers’ part.
Spengler points out that many people, including himself, had called out the suspicious patch submissions to Linux maintainers last year, but that it isn’t until now that these have been mass-actioned.
“…this overreaction is terrible, reverting commits from long before any of that research, removing CAP_SYS_ADMIN checks that were added, etc… This is nuts,” Spengler continued in the same thread.
Spengler also told BleepingComputer that not all of the reverted patches were necessarily malicious, warning that a decision to revert all patches could re-introduce bugs:
“It’s one thing to perform that review behind the scenes and only commit the result of that review, but to knowingly re-introduce dozens of vulnerabilities to ‘take a stand’? Come on.”
When contacted by BleepingComputer, Kroah-Hartman chose not to offer any further comment on the situation.
BleepingComputer reached out to the University of Minnesota for comment in advance of publishing this article but we did not hear back at the time.
The university has now issued a public statement and suspended this line of research, pending further investigation:
Apr 21 at 3:07 PM ET: added excerpts from FAQ compiled by UMN researchers.
Apr 22 at 1:26 AM ET: added twitter thread with statement from the University of Minnesota received hours after publishing.