Intentionally buggy commits for fame—and papers

This is hugely important and is why I am nervous about, eg, xda (for android roms and mods) where nearly everyone is pseudonymous.

In the kernel case, I would guess an institutional address helps more than a random gmail address with an unknown "real name" on it. Normally it would have been a plus if the institution was a well-known university.

Academic people should understand the reputation aspect. If you put out dubious research, you damage your own reputation. Which is what they did. There are pressures in academia, to publish, make headlines, generate funding. Sometimes people succumb to that pressure and end up hurting themselves.

Recently, before the incident at hand, there was a discussion on contributions from people using pseudonyms or aliases. Basically, there's no way of knowing if the names are real or not anyway, so it was suggested that you build reputation for an alias, and it does not matter if it's Reputable Name or Foo12345. It was also suggested that the requirement for using real name in submitting-patches.rst is outdated and does not reflect reality.

Surely we can't start requiring signed patches only from people within the web of trust...

How do you tell them apart from real names?
Inventing a plausible name doesn't seem to be a very hard thing to do.
And even if you personally do a detailed due diligence on each new contributor there are many maintainers to choose from, it's enough to find one too overworked to do that.

> In addition their contributions were detected as bad during the review process, rejected and eventually reverted. They proved the process works.

I think their "detection" owns much to the paper they have published where they described what their research is about.
As far as I know, these three earlier patches, that intentionally introduced bugs, that were submitted as a part of doing research for that paper weren't recognized as such at that time.

In general, I think the problem described in that paper is *very* real and have worried me a lot for years.

Even if kernel introduces some super-vetting process getting a vulnerability into a popular user space library is almost as good as getting one into kernel.
Besides that, there are also volunteer-run distributions, almost every one of them severely understaffed.

FreeBSD's PHK has made a good talk about this and much more *7 years ago*: https://www.youtube.com/watch?v=fwcl17Q0bpk
While he talked about an industry-wide subversion activities program by a state actor, there is also a part about subverting OSS (it starts around 23:30),
which certainly does not need nation-state resources to execute.

That's why I think that while we might disagree how the research was handled we he have to be careful not to shot the messenger.

Reminds me of the evil bit in RFC3514 :-)

Exactly. Right now they are on the horns of a dilemma: either they are intentionally introducing bad patches (in violation of appendix A in their own paper, though perhaps their *next* paper will have some *different* ethical wossname which its unconsenting subjects can't read yet because the paper isn't published)... or they are letting inexperienced students submit patches which are trivially determined to be buggy, which suggests that they're not doing any sort of preliminary review, which... well, if you're lining up a lot of newbie contributors to any project (as opposed to just being one newbie contributor yourself) it probably falls on you to give the first few submitted patches from any given contributor a once-over before submission, to make sure they're not terrible. This is routine in other large organizations (where "large" often means "more than a dozen people"): every project I've worked on for my current employer has had someone else internally look over the first few patches to make sure I wasn't screwing stuff up and wasting people's time. This was really good -- it reduced the stress quotient for me and probably also for upstream considerably, and the patches were better for it.

This research group inside UMN is apparently not doing any of that: they're using the kernel's limited review bandwidth as free tuition for their students. This is distinctly scummy. And that's the *good* fork of this dilemma, the one that just assumes ignorance or laziness rather than malice.

As someone who has to deal with IRB approval in the past:

You need IRB approval for literally everything that involves human beings in some form (which is the case here). For example, I had to write a 30 page document for an IRB approval to do a 2 page anonymous questionaire at the end of a software course.

Also, I would be highly surprised if the Minnesota IRB did not require "informed consent", i.e., a statement summarizing impact and consequences for potential participants and that has to be signed by participants before research can be conducted.

Institutional IRBs had been created specifically to ensure that "informed consent" is given in some form before any research is conducted...

In this case, the researchers didn't send their proposal to their IRB before doing the experiment - which is *already* a huge problem. IRBs are supposed to protect humans from experiments, how can that possibly work if the experiments happen first??? Their IRB then approved doing these experiments on humans without their consent, which is beyond the pale. GregKH specifically called the researchers out on this: "Our community does not appreciate being experimented on". Saying the word "process" does not suddenly change the rules or eliminate the humans; humans were fundamentally involved in the Linux kernel review process. If using the word "process" eliminated IRBs, then every medical experiment would suddenly investigate "metabolic processes" instead :-). I had to go through detailed IRBs just for surveys and interviews; this failure of oversight is a black mark on the whole university.

I think these researchers clearly acted unethically, and since they didn't ask for prior consent, they may have attacked other systems no matter what they say. I used the following shell command to search for potentially-concerning commits in git in one of my projects, other projects may want to do the same:

git shortlog --summary --numbered --email | grep -E '(wu000273|kjlu|@umn.edu)'

*All* OSS projects should review proposed changes for potential security issues, and harden their software & supply chain against attacks. I also welcome research to make that better!

But we don’t need researchers who perform attacks on production systems without authorization, or researchers who perform attacks on developers without their consent. Research is great, but you need to get permission from those you're attacking first.

Sure, a particular IRB can misapply the rules governing it, such as the ridiculous examples you list. But the solution is to work with the IRB (or its oversight) to fix them. You need to have people on the IRB who understand the domain, but nothing prevents that either.

I imagine IRBs could be improved, or replaced with something better. But the issue here is that we have researchers that experimented on humans without their consent. You don't need to be a rocket scientist to realize that such experiments are generally *not* acceptable.

Here, I see two faults:

1-: not seeking IRB approval first.

2-: either (yes, I can play devil's advocate), the IRB rubberstamped the study after the fact or else, the paper author lied about seeking IRB approval. Please take my concern with a grain of salt and no more than that; I'm just fresh out of an exam which took me 5 hours 45 minutes and I have to deliver 2 terms paperwork for next Monday 11:59pm, one of which isn't started yet. Otherwise, I would investigate.

Al

I agree that vitriol doesn't help. UMN should pay a trusted organization to help fix the damage to the kernel.

> Pakki said that the patches were based on the output of a new static analyzer that he wrote, but its "sensitivity is obviously not great".

He lied about what he was doing with the patches, how is this not malicious? If the NSA has done this we would obviously treat it as such.

The bigger issue, to me, is that they experimented on people without their consent. They also had very poor controls to be *confident* that their malicious changes would never end up in running systems, potentially putting end-users at risk (the Linux kernel is used in many very important systems). We can be thankful that the developers were proactive and detected attacks, but researchers are required to act ethically in the first place.

That does look like an innocent mistake though. The error condition under which the return with the lock held would happen cannot be controlled by an attacker (I believe it is an I2C read which fails) and even if it could at worse it would be a DOS attach AFAICT. Unless I'm again missing something ?

So buggy yes, malicious no. But now we still get to wonder if the buggy-ness was intentional or just an honest mistake <sigh>.

The second chunk looks like it's addressing a real problem that's not impossible to hit - lm80_read_value can return negative error codes and that wasn't being handled. Maybe that's only possible if there's a bizarre hardware failure (I2C/SMBus devices shouldn't just stop responding at arbitrary times) but it seems good practice for the kernel to handle those situations properly. (But the patch fixes the problem wrongly, because it returns without unlocking the mutex.)

Where did you see an apology to me and everyone else?

> I apologize for the misleading abstract which did not show the details and caused many confusions and misunderstandings.

> Throughout the study, we honestly did not think this is human research, so we did not apply for an IRB
approval in the beginning. We apologize for the raised concerns. This is an important lesson we
learned---Do not trust ourselves on determining human research; always refer to IRB whenever a study
might be involving any human subjects in any form.

> We would like to sincerely apologize to the maintainers involved in the corresponding
patch review process; this work indeed wasted their precious time.

> * The work taints the relationship between academia and industry
> We are very sorry to hear this concern.

There are tons of tools, but the very concept of "review" exists because at some point you need a human. And it turns out that a lot of tools and imposed processes can drain a lot of human time as well. In the end it's important to find a sweet balance of tools and processes that makes everyone work at their best efficiency.

Avoiding errors is pointless because they will always exist, and there are diminishing returns on the efforts you add. Instead what matters is that they're quickly spotted and fixed. Here the tools and automated tests in place are helping a lot.

Still more participants would be nice. If you don't review, why wouldn't you start ? Just spot a patch that you can read, from time to time, return some suggestions or respond with a "reviewed-by" so that nobody else spends time on it and you'll help by saving someone's valuable time. You don't necessarily need to be skilled on the subject if you can read code and be curious. It doesn't matter if you make a mistake once in a while (though not too often): if your work eliminates 90% of the someone else's work and requires to be fixed 10% of the time, it's already 81% saved!