[kdbg]

So kinda a quick summary given the available information that I've seen.

Back in August 2020 some research was performed looking at introducing vulnerabilities into the Linux Kernel.[0] The paper indicates that three patches were submitted via anonymous gmail accounts to the mailing list and were never committed. The reviewers were provided a proper patch upon accepting the vulnerable one and received explicit confirmation that the maintainers would not move forward with the vulnerable patch.

I'm not sure when exactly questions started being raised about that research. Though I first became aware of it in December. The discussion was mostly around the human involvement and led to the prepublication of the paper being removed and clarifications being issued.[1]

Fast-forward to April 2021. The patch seems to have kicked things off[2]. This was called out as being an impossible situation, and as being a "known-invalid patch" by Greg KH [3].

It appears that at least three patches by this same author introduced vulnerabilities[4] according to Leon Romanovsky. Though I don't have links to the specific patches.

Leading to U.Mn's ban from contributing to the kernel by Greg KH[5]

---------

What is in my opinion unclear at least to me is whether these more recent patches are actually in bad faith or just simply bad. The prevailing theory is that they are part of more research into introducing vulnerabilities. As already stated though, that research and its paper were done in August of 2020. The more recent commits, the official story from Kangjie Lu, Qiushi Wu, and Aditya Pakki[6] are that they are part of "a new project that aims to automatically identify bugs introduced by other patches". This does somewhat align with statements[7] made indicating that the commits were from a static analysis tool being researched which was made prior to this blowing up. Though I will note that the author of that patch was _not_ one of the authors of the apology letter, so may genuinely be unrelated.

This tool story was not believed by Greg KH[8].

And his take is the one that has gained a lot of adoption. That these patches were intentionally made in bad faith for another paper.

I will state that the newer patches that caused problems did _not_ follow the methodology that the original research followed to try to prevent vulnerabilities from actually being introduced into the repo. The original paper, while certainly had issues with methodology and experimenting on people inappropriately, did take steps to prevent any actual vulnerabilities from being committed, whereas the ones in question did not, and even made it to stable branches.

If the official story from U.Mn is true the commits should also have been noted as having been found by a tool, and followed the proper procedure for that, which they did not do. Though it does appear that the vast majority of the patches that were reverted were legitimate patches.[9] Atleast spot checking replies on that mailing list.

I mean on a whole the original research was questionable, but I kind of want to be more charitable in my interpretation of the more recent events but honestly that original patch that kicked things off is pretty bad.

[0] https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap...

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

[2] https://lore.kernel.org/linux-nfs/20210407001658.2208535-1-p...

[3] https://lore.kernel.org/linux-nfs/YH5%2Fi7OvsjSmqADv@kroah.c...

[4] https://lore.kernel.org/linux-nfs/YH+zwQgBBGUJdiVK@unreal/

[5] https://lore.kernel.org/linux-nfs/[e-mail]...

[6] https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJL...

[7] https://lore.kernel.org/lkml/CAAa=b7dnrz5Pz5hMUc29VHJb9ucFkW...

[8] https://lore.kernel.org/lkml/[e-mail]/

[9] https://lore.kernel.org/lkml/202104221451.292A6ED4@keescook/

[ncann]

I have followed the situation somewhat closely as well and there seem to be a lot of misinformation being thrown around. As far as I can tell (correct me if I'm wrong), no actual malicious commit has been found to be deliberately introduced and merged into the tree, and most of the recent commits that triggered this whole mess were from a claimed custom static analyzers that resulted in wrong/useless patches but not necessarily malicious.

I honestly think the situation is somewhat overblown, and some maintainers think so as well. To quote Jason Gunthorpe:

> So, this revert is based on not trusting the authors to carry out their work in the manner they explained? From what I've reviewed, and general sentiment of other people's reviews I've read, I am concerned this giant revert will degrade kernel quality more than the experimenters did - especially if they followed their stated methodology.

and Doug Ledford:

> I have to agree with Jason. This seems like trying to push a thumbtack into a bulletin board using a pyle driver. Unless the researchers are lying (which I've not seen a clear indication of), the 190 patches you have selected here are nothing more than collateral damage while you are completely missing the supposed patch submission addresses from which the malicious patches were sent!

https://lore.kernel.org/lkml/20210421180155.GA2287172@nvidia...

https://lore.kernel.org/lkml/18edc472a95f1d4efe3ef40cc9b8d26...

[openasocket]

> As far as I can tell (correct me if I'm wrong), no actual malicious commit has been found to be deliberately introduced and merged into the tree, and most of the recent commits that triggered this whole mess were from a claimed custom static analyzers that resulted in wrong/useless patches but not necessarily malicious.

My understanding is that the malicious commits described in their paper were submitted under alias email addresses, and the authors have not identified those addresses or the commits. So at this point there is no way to confirm that these malicious commits were properly reverted besides taking the authors word for it. To quote Mike Dolan's letter: "While the U of MN researchers claimed to take steps to prevent inclusion of vulnerabilities in the final software, their failure to gain consent suggests a lack of care. There are also amplified consequences because Linux kernel changes are picked up by many other downstream projects that build off of the kernel codebase." And I think it's fair for maintainers to question the competence and want to be able to verify everything, especially considering the consequences if the authors made a mistake.

But yes, assuming they used fake accounts, none of those 190 or so patches selected are the malicious ones from the paper. None of them appear to introduce any vulnerabilities, and the same for the weird commits from Aditya.