Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

21–30 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#21
From https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N...,

> A lot of these have already reached the stable trees.

If the researchers were trying to prove that it is possible to get malicious patches into the kernel, it seems like they succeeded -- at least for an (insignificant?) period of time.

Re: “They introduce kernel bugs on purpose”

#22
Later down thread from Greg K-H:

> Because of this, I will now have to ban all future contributions from your University.

Understandable from gkh, but I feel sorry for any unrelated research happening at University of Minnesota.

EDIT: Searching through the source code[1] reveals contributions to the kernel from umn.edu emails in the form of an AppleTalk driver and support for the kernel on PowerPC architectures.

In the commit traffic[2], I think all patches have come from people currently being advised by Kangjie Liu[3] or Liu himself dating back to Dec 2018. In 2018, Wenwen Wang was submitting patches; during this time he was a postdoc at UMN and co-authored a paper with Liu[4].

Prior to 2018, commits involving UMN folks appeared in 2014, 2013, and 2008. None of these people appear to be associated with Liu in any significant way.

[1]: https://github.com/torvalds/linux/search?q=%22umn.edu%22

[2]: https://github.com/torvalds/linux/search?q=%22umn.edu%22&typ...

[3]: https://www-users.cs.umn.edu/~kjlu/

[4]: http://cobweb.cs.uga.edu/~wenwen/

Re: “They introduce kernel bugs on purpose”

#24

From https://lore.kernel.org/linux-nfs/CADVatmNgU7t-Co84tSS6VW=3N... , > A lot of these have already reached the stable trees. If the researchers were trying to prove that it is possible to get malicious patches into the kernel, it seems like they succeeded -- at least for an (insignificant?) period of time.

I tangentially followed the debacle unfold for a while and this particular thread now has lead to heated debates on some IRC channels I'm on.

While it is maybe "scientifically interesting", intentionally introducing bugs into Linux that could potentially make it into production systems while work on this paper is going on, could IMO be described as utterly reckless at best.

Two messages down in the same thread, it more or less culminates with the university e-mail suffix being banned from several kernel mailing lists and associated patches being removed[1], which might be an appropriate response to discourage others from similar stunts "for science".

[1] https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah...

Re: “They introduce kernel bugs on purpose”

#25
post #8

Yikes, and what are they hoping to accomplish with this "research"?

What any researcher needs to accomplish: more publications

What journal is going to accept a study like this if they haven't obtained proper consent?

Re: “They introduce kernel bugs on purpose”

#26

Yikes, and what are they hoping to accomplish with this "research"?

They apparently made a tool to find vulnerabilities that could later lead to bugs is a different patch was introduced.

And for some insane reason, they decided to test if these kinds of bugs would be caught by inventing some and just submitting the patches, without informing anyone beforehand.

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

Re: “They introduce kernel bugs on purpose”

#29
post #2

I don't think there have been any recent comments from anyone at U.Mn. So, back when the original research (happened last year) the following clarification was offered by Qiushi Wu and Kangjie Lu which atleast paints their research in somewhat better light: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.... That said the current incident seems to have gone beyond the limits of that one and is a new incid…

From their explanation: (3). We send the incorrect minor patches to the Linux community through email to seek their feedback. (4). Once any maintainer of the community responds to the email, indicating “looks good”, we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all the three…

It does seem rather unethical, but I must admit that I find the topic very interesting. They should definitely have asked for consent before starting with the "attack", but if they did manage to land security vulnerabilities despite the review process it's a very worrying result. And as far as I understand they did manage to do just that?

I think it shows that this type of study might well be needed, it just needs to be done better and with the consent of the maintainers.

Post reply on HN