Hacker News Reader

Comment by ltfish | Hacker News Reader

Some clarifications since they are unclear in the original report.

- Aditya Pakki (the author who sent the new round of seemingly bogus patches) is not involved in the S&P 2021 research. This means Aditya is likely to have nothing to do with the prior round of patching attempts that led to the S&P 2021 paper.

- According to the authors' clarification [1], the S&P 2021 paper did not introduce any bugs into Linux kernel. The three attempts did not even become Git commits.

Greg has all reasons to be unhappy since they were unknowingly experimented on and used as lab rats. However, the round of patches that triggered his anger *are very likely* to have nothing to do with the three intentionally incorrect patch attempts leading to the paper. Many people on HN do not seem to know this.

[1] https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....

View on HN

Aditya's advisor [1] is one of the co-authors of the paper. He at least knew about this work and was very likely involved with it.

[1] https://adityapakki.github.io/assets/files/aditya_cv.pdf

There is no doubt that Kangjie is involved in Aditya's research work, which leads to bogus patches sent to Linux devs. However, based on my understanding of how CS research groups usually function, I do not think Kangjie knew the exact patches that Aditya sent out. In this specific case, I feel Aditya is more likely the one to blame: He should have examined these automatically generated patches more carefully before sending them in for reviewing.

Kangjie should not have approved any research plan involving kernel patches knowing that he had already set that relationship on fire in order to get a prior paper published.

>based on my understanding of how CS research groups usually function

If you mean supervisors adding their names on to publications without having contributed any work, than this is not only limited to CS research groups. Authorship misrepresentation is widespread in academia and unfortunately mostly being ignored. Those who speak up are being singled out and isolated instead.

I would say it's less authorship misrepresentation and more an established convention that's well-known to people within the field. Lead authors go first, then supporting contributors, and finally advisors at the end.

Where I went, it was so widespread that it was considered normal and nobody would even think about speaking out about it. Only with hindsight did I realize how despicable it was.

At my last job a low quality paper was written about "my work" despite me saying that it's too early. It was based on my idea and resulted in our research groups grant participation being extended, despite our professor saying that the grant won't be extended since he switched universities and continent.

It was written while I was working on the software and my name was then put in third position on the list of authors. Only way I was able to defend myself was, asking them to remove my name from the paper which resulted in the paper not being published.

Even if they didn't write or perform part of the research, they did act in an advisory or consulting fashion, and therefore could significantly shape the research. Maybe there should be a different way to credit that, but right now convention is to put them in a low position in the list of authors.

Aditya's story about the new patches is that he was writing a static analysis tool and was testing it by... submitting PRs to the Linux kernel? He's either exploiting the Linux maintainers to test his new tool, or that story's bullshit. Even taking his story at face value is justification to at least ban him personally IMO.

People do this with static analysis tools all the time. It’s obnoxious but not necessarily malicious.

To be clear: asking Linux maintainers to verify the results of static analysis tools they wrote themselves, without admitting to it until they're accused of being malicious?

Asking Linux maintainers to apply patches or fix “bug” resulting from home grown static analysis tools, which usually flag all kinds of things that aren’t bugs. This happens regularly.

As someone who used to maintain a large C++ codebase, people usually bug-dump static analysis results rather than actually submitting fixes, but blindly "fixing" code that a static analysis tool claims to have issue with is not surprising to see either.

If the patches were accepted, the person could have used those fixes to justify the benefits of the static analysis tool they wrote.

They generally state that this was found with so-and-so static analysis tool. And, as GKH pointed out in the thread, the resulting patches generally make changes that match a certain pattern, not the random uselessness that Aditya's patches were.

I'm unclear why one cannot do all these tests with a fork.

Sounds like these commits aren't related to that paper, they're related to the next paper he's working on, and the next one is making the same category error about human subjects in his study.

This is Aditya Pakki's webiste:

https://adityapakki.github.io/

In this "About" page:

https://adityapakki.github.io/about/

he claims "Hi there! My name is Aditya and I’m a second year Ph.D student in Computer Science & Engineering at the University of Minnesota. My research interests are in the areas of computer security, operating systems, and machine learning. I’m fortunate to be advised by Prof. Kangjie Lu."

so he in no uncertain terms is claiming that he is being advised in his research by Kangjie Lu. So it's incorrect to say his patches have nothing to do with the paper.

> So it's incorrect to say his patches have nothing to do with the paper.

Professors usually work on multiple projects, which involve different grad students, at the same time. Aditya Pakki could be working on a different project with Kangjie Lu, and not be involved with the problematic paper.

Sucks to be him then. He can thank his professor.

Based on the tone of his email, I would say that the ban is not entirely undeserved.

Clearly in over his head though.

I would encourage you not to post people's contact information publicly, specially in a thread as volatile as this one. Writing "He claims in his personal website" would bring the point across fine.

This being the internet, I'm sure the guy is getting plenty of hate mail as it is. No need to make it worse.

They are named in the comment above. Aditya Pakki's personal website is the first result upon Googling that name.

I doubt HN has the volume of readership/temperament to lead to substantial hate mail (unlike, say, Twitter).

I would hope most here are above spamming hatemail to things they aren't involved with...

> S&P 2021 paper did not introduce any bugs into Linux kernel.

I used to work as an auditor. We were expected to conduct our audits to neither expect nor not expect instances of impropriety to exist. However, once we had grounds to suspect malfeasance, we were "on alert", and conduct tests accordingly.

This is a good principle that could be applied here. We could bat backwards and forwards about whether the other submissions were bogus, but the presumption must now be one of guilt rather than innocence.

Personally, I would have been furious and said, in no uncertain terms, that the university keep a low profile and STFU lest I be sufficiently provoked to taking actions that lead to someone's balls being handed to me on a plate.

What sort of lawsuit might they bring against a university whose researchers deliberately inserted malicious code into software that literally runs a good portion of the world?

I'm no lawyer, but it seems like there'd be something actionable.

On a side note, this brings into question any research written by any of the participating authors, ever. No more presumption of good faith.

Not just this world, other worlds too [0].

The first extraterrestrial software crime?

[0] https://www.theverge.com/2021/2/19/22291324/linux-perseveran...

>What sort of lawsuit might they bring against a university whose researchers deliberately inserted malicious code into software that literally runs a good portion of the world?

I am also not a lawyer, but aside from any civil action, the conduct looks like it might be considered criminal under the Computer Fraud and Abuse Act:

"Whoever knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer;"

https://www.law.cornell.edu/uscode/text/18/1030#a_5

> According to the authors' clarification [1], the S&P 2021 paper did not introduce any bugs into Linux kernel. The three attempts did not even become Git commits.

Except that at least one of those three, did [0]. The author is incorrect that none of their attempts became git commits. Whatever process that they used to "check different versions of Linux and further confirmed that none of the incorrect patches was adopted" was insufficient.

[0] https://lore.kernel.org/patchwork/patch/1062098/

> The author is incorrect that none of their attempts became git commits

That doesn't appear to be one of the three patches from the "hypocrite commits" paper, which were reportedly submitted from pseudononymous gmail addresses. There are hundreds of other patches from UMN, many from Pakki[0], and some of those did contain bugs or were invalid[1], but there's currently no hard evidence that Pakki was deliberately making bad-faith commits--just the association of his advisor being one of the authors of the "hypocrite" paper.

[0] https://github.com/torvalds/linux/commits?author=pakki001@um...

[1] Including his most recent that was successfully applied: https://lore.kernel.org/lkml/YH4Aa1zFAWkITsNK@zeniv-ca.linux...

But Kanjie Lu, Pakki’s advisor, was one of the authors. The claim that “ You, and your group, have publicly admitted to sending known-buggy patches” may not be totally accurate (or it might be—Pakki could be on other papers I’m not aware of), but it’s not totally inaccurate either. Most academic work is variations on a theme, so it’s reasonable to be suspect of things from Lu’s group.

As Greg KH notes, he has no time to deal with such BS, when suggested to write a formal complain. He has no time to play detectives: you are involved in a group that does BS and this smell like BS again, banned.

Unfair? Maybe: complain to your advisor.

It shouldn’t be up to the victim to sort that out. The only thing that could perhaps have changed here is for the university wide ban to have been announced earlier. Perhaps the kernel devs assumed that no one would be so shameless as to continue to send students back to someone they had already abused.

The person in power here is Greg KH. It seems like he can accept/reject/ban anyone for any reason with little recourse for the counter-party. I'm willing to withhold judgement on these allegations until the truth comes out. Seems like many here want retribution before any investigation.

You realise that the evidence is already there plain for everyone to see. It's even laid out in the email thread we're commenting on. This sort of linguistic weaseling doesn't help anyone, least of all folks who may not understand the entire context of what went down here (which is much worse than it might seem on the face of it).

In an evolving situation, I hesitate to immediately accept something as fact just because its in a comment. I don't believe in online "mob justice", nor in guilt by association.

You seem convinced, I am not. And as such, we just have a disagreement, no biggie. :)

>This sort of linguistic weaseling doesn't help anyone, least of all folks who may not understand the entire context of what went down here (which is much worse than it might seem on the face of it).

I am expressing an opinion, just as you are.

There's only one way the kernel dev team can afford to look at this: A bad actor tried to submit malicious code to the kernel using accounts on the U of M campus. They can't afford to assume that the researchers weren't malicious, because they didn't follow the standards of security research and did not lay out rules of engagement for the pentest. Because that trust was violated, and because nobody in the research team made the effort to contact the appropriate members of the dev team (in this case, they really shoulda taken it to Torvalds), the kernel dev team can't risk taking another patch from U of M because it might have hidden vulns in it. For all we know, Aditya Pakki is a pseudonym. For all we know, the researchers broke into Aditya's email account as part of their experiment--they've already shown that they have a habit of ignoring best practices in infosec and 'forgetting' to ask permission before conducting a pentest.

I agree, the kernel team shouldn't make decisions based on the intents to submit such patches.

Like you can go to any government building with a threat of bombs but claiming it is only an experiment to find security loophole.

It is worth noting that Pakki is one of the paper’s writer’s (Lu) assistants.

https://adityapakki.github.io/experience/

From his message, the ones that triggered his anger were patches he believed to be obviously useless and therefore either incompetently submitted or submitted as some other form experimentation. After the intentionally incorrect patches, he could no longer allow the presumption of good faith.

It doesn't matter. I think this is totally appropriate. A group of students are submitting purposely buggy patches? It isn't the kernels team to sift through and distinguish they come down and nuke the entire university. This sends a message to any other University thinking of a similar stunt you try this bull hockey you and your entire university are going to get caught in the blast radius.

In short "f** around, find out"

On the plus side, I guess they get a hell of a result for that research paper they were working on.

"We sought to probe vulnerabilities of the open-source public-development process, and our results include a methodology for getting an entire university's email domain banned from contributing."

Which will (hopefully) not be accepted by any reputable journal.

Given the attitude of "the researchers" and an earlier paper [1] so far, somehow I doubt they will act in good faith this time.

For instance:

"D. Feedback of the Linux Community. We summarized our findings and suggestions, and reported them to the Linux community. Here we briefly present their feedback. First, the Linux community mentioned that they will not accept preventive patches and will fix code only when it goes wrong. They hope kernel hardening features like KASLR can mitigate impacts from unfixed vulnerabilities. Second, they believed that the great Linux community is built upon trust. That is, they aim to treat everyone equally and would not assume that some contributors might be malicious. Third, they mentioned that bug-introducing patches is a known problem in the community. They also admitted that the patch review is largely manual and may make mistakes. However, they would do their best to review the patches. Forth, they stated that Linux and many companies are continually running bug-finding tools to prevent security bugs from hurting the world. Last, they mentioned that raising the awareness of the risks would be hard because the community is too large."

[1] https://raw.githubusercontent.com/QiushiWu/qiushiwu.github.i...

That is just appalling. I'm glad these jokers used their real names; it will be easier to avoid them in the future.

I seriously doubt this policy would have been adopted if other unrelated groups at the same university were submitting constructive patches.

I read through that clarification doc. I don't like their experiment but I have to admit their patch submission process is responsible (after receiving a "looks good" for the bad patch, point out the flaw in the patch, give the correct fix and make sure the bad patch doesn't get into the tree).

Reply on news.ycombinator.com