Linux Foundation Bans University After It Intentionally Submitted Buggy Patches

News
By Nathaniel Mott
published

Stable as they go.

Penguins
(Image credit: Shutterstock)

The University of Minnesota isn't making any friends in the Linux community. Phoronix reported that Greg Kroah-Hartman, the Fellow at the Linux Foundation responsible for stable releases of the Linux kernel, has banned the University from contributing to that kernel after two students purposely added faulty code to it.

The students in question published a research paper titled "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits" on February 10. Those so-called "hypocrite commits" were defined as "seemingly beneficial commits that in fact introduce other critical issues."

Although the paper was ostensibly focused on open source software generally, the students devoted much of their attention to the Linux kernel specifically because it's so popular. The kernel is practically ubiquitous—it's found in everything from single-board computers like the Raspberry Pi to the most powerful supercomputers.

All of which is to say that Linux is vital. It would make sense, then, for the person responsible for the Linux kernel's stable release branch to be upset about those students' efforts to undermine that project. Kroah-Hartman made his stance on the issue clear in a message posted to the Linux kernel mailing list earlier today:

"Our community does not appreciate being experimented on, and being 'tested' by submitting known patches that are either do nothing [sic] 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."

Kroah-Hartman also said that he "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." It seems that research conducted by two students will now affect the entire University of Minnesota.

That actually includes five schools spread across Crookston, Duluth, Morris, Rochester, and Twin Cities. We've reached out to the overarching University of Minnesota as well as Kroah-Hartman to learn more about the full extent of the ban and will update this post if either responds to our request for more information.

Nathaniel Mott
Nathaniel Mott
Freelance News & Features Writer

Nathaniel Mott is a freelance news and features writer for Tom's Hardware US, covering breaking news, security, and the silliest aspects of the tech industry.

18 Comments Comment from the forums
  • hotaru.hino
    The premise of their paper makes sense: given a large enough OSS project, it may be impractical for its maintainers to analyze every single commit for potential issues.

    Their execution? Yeah that was a mistake.
    Reply
  • Matt_ogu812
    Banning the University of Minnesota amounts to a slap on the wrist and nothing more.
    The culprit(s) are still free to cause more damage if so desired.
    How about a stiff monetary fine along with some jail time.
    Reply
  • Exploding PSU
    A somewhat similar incident happened in my university. A group of brilliant students wanted to do some "security tests" for their final paper. They tested their proposed method against some ISP-related networks without asking for permissions first (or something like that, I heard this from my professor so details are rather scarce, and I'm no networking guy).

    While their method was valid and there was indeed an exploitable vulnerability, the fact they tested it without asking for permission first got the university into deep troubles with several ISPs, even the dean had to reason with the ISP and there was some monetary damages.

    My professor used that incident as a real example of "the road to hell is paved with good intentions".
    Reply
  • jkflipflop98
    As opposed to all the other patches which are unintentionally buggy.
    Reply
  • hannibal
    Well this is the strong point and weaknes of Linux. Any Person can contribute and any Person can cheack out the code. So hoax can be found.
    The problem is that any Person can also make havok by making ”mal code” to the system and there is posibility that that code gets in the release version. And that was the point of what those students did try to prove. Just like some studenst would like to prove that a bank can be robbed, by making a robbery for the name of science ;)

    Hopefully this even increase the check and cross check testing of Linux code before it goes to release stage.
    Reply
  • LawlessQuill
    Why didn't they release the names of the students? They should be blacklisted from the industry and put on a watchlist, I don't care if it's on the books legally or socially agreed upon, release their names! No one will hire them
    Reply
  • hotaru.hino
    LawlessQuill said:
    Why didn't they release the names of the students? They should be blacklisted from the industry and put on a watchlist, I don't care if it's on the books legally or socially agreed upon, release their names! No one will hire them
    And then give them more incentive to resort to criminal activities if this is a strong area of interest.

    Sounds good.
    Reply
  • TJ Hooker
    So much misinformation circling about this story, along with people filling in their own details as they go. Anyone interested in what actually happened should probably take a look at the research paper in question and the relevant linux kernel maintainers' email thread.

    The researchers who wrote the paper only created three 'bad' patches. They took steps to ensure that these patches never actually made it into the kernel, as well as tried to minimize the impact on the maintainers' time. See section VI-A in the paper. So people should probably put down their pitchforks. As an aside, it wasn't two students; it was a student and a prof.

    At some later date, another person/people from the university submitted some more patches. It's not clear if they have a direct relation to the two authors, other than working at the same place. These patches do not appear to be malicious, but maintainers felt that they were largely useless and/or time-wasting submissions. The submitters claim the patches were the result of the output of a new static analysis tool they were trying out, and insist they were submitted in good faith (which the maintainers didn't buy). This is, along with the 'experiment' the two researchers conducted, are what prompted Kroah-Hartman's statement.

    With regard to Kroah-Hartman's statement about "rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems", he was seemingly referring to all past contributions from people with umn.edu email addresses (not necessarily the author's of the paper). As far as I'm aware there's no evidence that these past submissions had (deliberate) vulnerabilities, and in the email thread one of the maintainers' even vouches for some of the past patches as being legit.
    Reply
  • punkncat
    jkflipflop98 said:
    As opposed to all the other patches which are unintentionally buggy.

    The significant differentiating aspect is intent.

    You may make code that in good faith you believe should work right over the majority of the machines running the software.

    You purposefully create malicious aspect to your code so that you can prove a point for a paper and grade in a class. It crossed the line to black hat, plain and simple.
    Reply
  • TJ Hooker
    hotaru.hino said:
    Their execution? Yeah that was a mistake.
    To be honest, I'm not sure what the right way to do this would have been. They didn't even create pull requests so there was no real chance of their 'bad' patches getting in, so there's no concern there. So we're left with the concern of wasting people's time, and 'experimenting' on people without their knowledge . The problem is you can't tell the person who will be reviewing the patches, as that would obviously affect the result. And even if you tell one of the other maintainers, they're not in a position to give you permission to conduct the expirement on a different maintainer, as no one is anyone else's boss that they're in a position to speak for the other's time. They did try to mitigate the time aspect, by making the patches only a few lines long. They justify not receiving consent from the experiment 'participants' by saying that the experiment is being conducted on the procedures/systems in place, not on individuals, thus there are no human ethical concerns (which the school's research review board apparently agreed with). But that justification can obviously be debated.
    Reply