The Linux kernel is one of the largest software projects in the modern history; with a gigantic 28 millions lines of code.
Contributors from all over the world and from different fields submit a large number of patches each day to the Linux kernel maintainers, so that they get reviewed before being officially merged to the official Linux kernel tree.
These patches could help fix a bug or a minor issue in the kernel, or introduce a new feature.
However, some contributors have been caught today trying to submit patches stealthily containing security vulnerabilities to the Linux kernel, and they were caught by the Linux kernel maintainers.
Researchers from the US University of Minnesota were doing a research paper about the ability to submit patches to open source projects that contain hidden security vulnerabilities in order to scientifically measure the probability of such patches being accepted and merged. Which could make the open source projects vulnerable to various attacks.
They used the Linux kernel as one of their main experiments, due to its well-known reputation and adaptation around the world.
These researchers submitted patches which didn’t seem to completely fix the related issues in the kernel, but also didn’t right away seem to introduce a security vulnerability.
However, today, they were caught by Linux kernel maintainers, and were publicly humiliated. In an email by Greg Kroah-Hartman, one of the major Linux kernel maintainers, their approach was disclosed and their so-called “newbie patches” were thrown under the bus:
You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work.
Now you submit a new series of obviously-incorrect patches again, so what am I supposed to think of such a thing?
Apparently, Greg and a number of other maintainers were not happy about this, as these experiments consume their time and efforts and make people engage by bad faith in the Linux kernel development:
Our community does not appreciate being experimented on, and being “tested” by submitting known patches that are either do nothing on purpose, or introduce bugs on purpose. 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.
Finally, Greg announced that the Linux kernel will ban all contributions from the University of Minnesota, and that all the patches they previously submitted are going to be removed from the kernel, and no new patches will be accepted from them in the future:
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.
The research paper they worked on was published back in February, 2021; around two months ago. In the paper, they disclose their approach and methods that they used to get the vulnerabilities inserted to the Linux kernel.
The main issue in their approach is that they didn’t connect beforehand with Greg and other kernel maintainers before doing their research. Normally, in such projects, agreement of the software owner is retrieved before stealthy trying to push such code, so that maintainer time is not wasted in reviewing these commits, nor there is a probability for them to be merged by mistake in the main kernel line.
Greg has sent another email in which he reverts most patches from the University of Minnesota from the Linux kernel, and puts some of them on hold.
Discussion: What do you think about this approach? Do you think that the researcher’s attitudes were justified in favor of science and security? Or do you think that the Linux kernel maintainers were right in banning them from the kernel, and that this approach should not be encouraged?
Update: The article was updated to reflect more accurate detailed on the matter. The ban is now lifted on the University of Minnesota, and the following TAB report was issued: https://lwn.net/ml/linux-kernel/202105051005.49BFABCE@keescook/