Linux prohibits the University of Minnesota from committing malicious code

In a rare, groundbreaking decision, Linux kernel project administrators banned 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 to the official Linux codebase as part of their investigative activities.

In addition, the Linux kernel project administrators have decided to delete all code commits ever submitted from a @ umn.edu email addresses.

Malicious commits massively rolled back, 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 has also decided to undo all commits submitted so far from any UMN email address.

The developer’s justification for taking this step is:

“Commit to @ umn.edu Addresses have been identified as being submitted in bad faith to attempt to test the ability of the kernel community to assess “known malicious” changes. “

“Therefore, all submissions from this group must be rolled back from the kernel tree and reassessed to determine if they are actually a valid solution.”

Until that work is done, [we are removing] this change to ensure that no issues are introduced into the codebase, ”said Kroah-Hartman in a series of published emails.

In February 2021, UMN researchers published a research article entitled: “Open source uncertainty: covertly introducing vulnerabilities through hypocritical commits. “

The focus of this research was to deliberately introduce known security vulnerabilities into 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 creating these “hypocritical” patch commits:

Introducing the destroyed state is easy. The patch is seemingly valid because it nullifies pf-> disk-> queue after the pointer is released. “

“Some features such as pf_detect () and pf_exit () after this destruction, and they would further de-reference this pointer without checking its status, leading to a NULL pointer, ”UMN researchers say in their paper.

As BleepingComputer has seen, there are hundreds of commits touting themselves as ‘patches’ that have been rolled back as part of this process:

UMN researchers call the allegations ‘defamation’

Soon, UMN researcher Aditya Pakki pushed back, asking Kroah-Hartman to refrain from “ wild allegations bordering on defamation. ”

Pakki wrote:

To which Kroah-Hartman replied that the Linux kernel developer community does not appreciate being experimented in this way.

“If you want to do this kind of work, I recommend that you find another community to conduct your experiments on, you are not welcome here,” said Kroah-Hartman.

“Therefore, I will now have to ban all future contributions from your university and take out your previous contributions, as they were clearly submitted in bad faith with the intention of causing problems,” he continued.

Last year, UMN researchers had produced a detailed FAQ document in which they stated that the purpose of this study was to improve the security of the patching process in open-source software by demonstrating the usefulness of bug-introducing patches.

The researchers also stated that any patch suggestions were made via email exchanges and never ended up in a 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 approved the research activities.

While the researchers sincerely apologized to Linux administrators for the time they wasted reviewing “hypocritical” patches:

“We would like to offer our sincere apologies to the administrators involved in the corresponding patch review process; this work has indeed wasted their precious time.”

“We had carefully considered this problem, but could not come up with a better solution in this study,” say the researchers.

Brad Spengler, President of Open Source Security Inc. weighed in on the issue, calling it an “overreaction” from the Linux kernel administrators.

Spengler points out that many people, including himself, shouted suspicious patch submissions to Linux administrators last year, but that massive action has only now been taken.

What a mess, several people (including myself) tried to warn them last year: https://t.co/kl7tfKAqXj and now this overreaction: https://t.co/twOgboRFIR is going to cause a lot more work for everyone

– Brad Spengler (@spendergrsec) April 21, 2021

“… this overreaction is awful, deleting the rollback of records from long before that investigation CAP_SYS_ADMIN checks added, etc … This is crazy, ”Spengler continued in the same thread.

Spengler also told BleepingComputer that not all patches patched were necessarily malicious, and warned that a decision to roll back all patches could reintroduce bugs:

“It’s one thing to run that review behind the scenes and capture only the outcome of that review, but deliberately reintroduce dozens of vulnerabilities to ‘take a stand’? Come on.”

When Kroah-Hartman contacted BleepingComputer, he chose not to comment further on the situation.

BleepingComputer reached out to the University of Minnesota for comment before publishing this article, but we didn’t hear back then.

The university has now issued a public statement suspending this line of research, pending further investigation:

The research method used caused serious concern in the Linux Kernel community and as of today has resulted in the university being banned from contributing to the Linux Kernel.

– UMNComputerScience (@UMNComputerSci) April 21, 2021

Updates:

April 21 at 3:07 PM ET: excerpts added from FAQ compiled by UMN researchers.

April 22 at 1:26 AM ET: Twitter thread added with statement from University of Minnesota, received hours after publication.