7 ms·

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 involve

by ltfish 5y ago

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.pdf https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....

hpoe 5y ago
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"
- shadowgovt 5y ago
  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."
  - the_duke 5y ago
    Which will (hopefully) not be accepted by any reputable journal.
  - mirchibajji 5y ago
    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.io/main/papers/OpenSourceInsecurity.pdf https://raw.githubusercontent.com/QiushiWu/qiushiwu.github.i...
    - _jal 5y ago
      That is just appalling. I'm glad these jokers used their real names; it will be easier to avoid them in the future.
- seoaeu 5y ago
  I seriously doubt this policy would have been adopted if other unrelated groups at the same university were submitting constructive patches.
rideontime 5y ago
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.
- amluto 5y ago
  People do this with static analysis tools all the time. It’s obnoxious but not necessarily malicious.
  - rideontime 5y ago
    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?
    - amluto 5y ago
      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.
    - MikeHolman 5y ago
      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.
  - azernik 5y ago
    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.
timdorr 5y ago
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 https://adityapakki.github.io/assets/files/aditya_cv.pdf
- ltfish 5y ago
  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.
  - bradleyjg 5y ago
    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.
  - de6u99er 5y ago
    >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.
    - mintplant 5y ago
      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.
    - rtsil 5y ago
      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.
rflrob 5y ago
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.
- otherme123 5y ago
  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.
deleted 5y ago
[deleted]
peanut_worm 5y ago
It is worth noting that Pakki is one of the paper’s writer’s (Lu) assistants. https://adityapakki.github.io/experience/ https://adityapakki.github.io/experience/
oraged 5y ago
This is Aditya Pakki's webiste: https://adityapakki.github.io/ https://adityapakki.github.io/ In this "About" page: https://adityapakki.github.io/about/ 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.
- Denvercoder9 5y ago
  > 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.
  - varjag 5y ago
    Sucks to be him then. He can thank his professor.
    - g42gregory 5y ago
      Based on the tone of his email, I would say that the ban is not entirely undeserved.
      - asveikau 5y ago
        Clearly in over his head though.
- probably_wrong 5y ago
  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.
deleted 5y ago
[deleted]
bradleyjg 5y ago
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.
- passivate 5y ago
  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.
  - krageon 5y ago
    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).
    - passivate 5y ago
      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.
blippage 5y ago
> 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.
- ineedasername 5y ago
  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.
  - austinjp 5y ago
    Not just this world, other worlds too [0]. The first extraterrestrial software crime? [0] https://www.theverge.com/2021/2/19/22291324/linux-perseverance-mars-curiosity-ingenuity https://www.theverge.com/2021/2/19/22291324/linux-perseveran...
  - ddeck 5y ago
    >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 https://www.law.cornell.edu/uscode/text/18/1030#a_5
ncann 5y ago
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).
shakna 5y ago
> 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/ https://lore.kernel.org/patchwork/patch/1062098/
- re 5y ago
  > 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@umn.edu 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.org.uk/ https://lore.kernel.org/lkml/YH4Aa1zFAWkITsNK@zeniv-ca.linux...
ineedasername 5y ago
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.
dawnbreez 5y ago
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.
- karmasimida 5y ago
  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.

by ltfish 5y ago

hpoe 5y ago

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"

shadowgovt 5y ago
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."
- the_duke 5y ago
  Which will (hopefully) not be accepted by any reputable journal.
- mirchibajji 5y ago
  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.io/main/papers/OpenSourceInsecurity.pdf https://raw.githubusercontent.com/QiushiWu/qiushiwu.github.i...
  - _jal 5y ago
    That is just appalling. I'm glad these jokers used their real names; it will be easier to avoid them in the future.
seoaeu 5y ago
I seriously doubt this policy would have been adopted if other unrelated groups at the same university were submitting constructive patches.

rideontime 5y ago

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.

amluto 5y ago
People do this with static analysis tools all the time. It’s obnoxious but not necessarily malicious.
- rideontime 5y ago
  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?
  - amluto 5y ago
    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.
  - MikeHolman 5y ago
    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.
- azernik 5y ago
  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.

timdorr 5y ago

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 https://adityapakki.github.io/assets/files/aditya_cv.pdf

ltfish 5y ago
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.
- bradleyjg 5y ago
  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.
- de6u99er 5y ago
  >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.
  - mintplant 5y ago
    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.
  - rtsil 5y ago
    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.

rflrob 5y ago

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.

otherme123 5y ago
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.

deleted 5y ago

[deleted]

peanut_worm 5y ago

It is worth noting that Pakki is one of the paper’s writer’s (Lu) assistants. https://adityapakki.github.io/experience/ https://adityapakki.github.io/experience/

oraged 5y ago

This is Aditya Pakki's webiste: https://adityapakki.github.io/ https://adityapakki.github.io/ In this "About" page: https://adityapakki.github.io/about/ 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.

Denvercoder9 5y ago
> 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.
- varjag 5y ago
  Sucks to be him then. He can thank his professor.
  - g42gregory 5y ago
    Based on the tone of his email, I would say that the ban is not entirely undeserved.
    - asveikau 5y ago
      Clearly in over his head though.
probably_wrong 5y ago
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.

deleted 5y ago

[deleted]

bradleyjg 5y ago

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.

passivate 5y ago
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.
- krageon 5y ago
  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).
  - passivate 5y ago
    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.

blippage 5y ago

> 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.

ineedasername 5y ago
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.
- austinjp 5y ago
  Not just this world, other worlds too [0]. The first extraterrestrial software crime? [0] https://www.theverge.com/2021/2/19/22291324/linux-perseverance-mars-curiosity-ingenuity https://www.theverge.com/2021/2/19/22291324/linux-perseveran...
- ddeck 5y ago
  >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 https://www.law.cornell.edu/uscode/text/18/1030#a_5

ncann 5y ago

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).

shakna 5y ago

> 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/ https://lore.kernel.org/patchwork/patch/1062098/

re 5y ago
> 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@umn.edu 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.org.uk/ https://lore.kernel.org/lkml/YH4Aa1zFAWkITsNK@zeniv-ca.linux...

ineedasername 5y ago

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.

dawnbreez 5y ago

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.

karmasimida 5y ago
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.