Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

241–250 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#241
Since there is bound to be a sort of trust hierarchy in these commits, is it possible that bonafide name-brand university people/email addresses come with an imprimatur that has now been damaged generally?

Given the size and complexity of the Linux (/GNU) codeworld, I have to wonder if they are coming up against (or already did) the practical limits of assuring safety and quality using the current model of development.

Re: “They introduce kernel bugs on purpose”

#242

So how does this differ from the Sokal hoax thing?

Sokal didn't try to pass harmful ideas, just nonsense.

The patch in the posted mail thread is mostly harmless nonsense too. It's a no-op change that doesn't introduce a bug; at worst it makes the code slightly less readable.

Re: “They introduce kernel bugs on purpose”

#243

Earlier quoted context omitted.

> I think all patches have come from people currently being advised by Kangjie Liu[3] or Liu himself dating back to Dec 2018 New plan: Show up at Liu's house with a lock picking kit while he's away at work, pick the front door and open it, but don't enter. Send him a photo, "hey, just testing, bro! Legitimate security research!"

If they wanted to do security research, they could have done so in the form of asking the reviewers to help; send them a patch and ask 'Is this something you would accept?', instead of intentionally sending malicious commits and causing static on the commit tree and mailing lists.

Even better

Notify someone up the chain that you want to submit malicious patches, and ask them if they want to collaborate.

If your patches make it through, treat it as though they essentially just got red teamed, everyone who reviewed it and let it slip gets to have a nervous laugh and the commit gets rejected, everyone having learned something.

Re: “They introduce kernel bugs on purpose”

#244

Earlier quoted context omitted.

If the IRB is any good the professor doesn't get that. Universities are publish or perish, and the IRB should force the withdrawal of all papers they submitted. This is might be enough to fire the professor with cause - including remove any tenure protection they might have - which means they get a bad reference. I hope we hear from the IRB in about a year stating exactly what happened. Real investigations of bad con…

See page 9 of the already published paper: https://raw.githubusercontent.com/QiushiWu/qiushiwu.github.i... > We send the emails to the Linux communityand seek their feedback. The experiment is not to blame any maintainers but to reveal issues in the process. The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. We obtained a formal IRB-exempt lett…

> We send the emails to the Linux communityand seek their feedback.

That's not really what they did.

They sent the patches, the patches where either merged or rejected.

And they never let anybody knew that they had introduced security vulnerabilities on the kernel on purpose until they got caught and people started reverting all the patches from their university and banned the whole university.

Re: “They introduce kernel bugs on purpose”

#245
post #226

The professor gets exactly what they want here, no? "We experimented on the linux kernel team to see what would happen. Our non-double-blind test of 1 FOSS maintenance group has produced the following result: We get banned and our entire university gets dragged through the muck 100% of the time". That'll be a fun paper to write, no doubt. Additional context: * One of the committers of these faulty patches, Aditya Pak…

Hearing how you phrased it reminds me of a study that showed how parachutes do not in fact save lives (the study was more to show the consequences of extrapolating data, so the result should not be taken seriously): https://www.bmj.com/content/363/bmj.k5094

This is now my second favourite paper after the atlantic salmon in fmri

Re: “They introduce kernel bugs on purpose”

#246

I feel like q lot of people here did not interpret this correctly. As far as it's known, garbage code was not introduced into kernel.It was caught in the review process literally on the same day. However, there has been merged code from the same people, which is not necessarily vulnerable. As a precaution the older commits are also being reverted, as these people have been identified as bad actors

Note that the commits which have been merged previously have also been intentionally garbage and misleading code, just without any obvious way to exploit them. For example, https://lore.kernel.org/lkml/20210407000913.2207831-1-pakki0... has been accepted since April 7, and it's an obviously a commit meant to _look_ like a bug fix while having no actual effect. (The line `rm = NULL;` and the line `if (was_on_sock && rm)` operate on different variables called `rm`.)

That means that the researchers got bogus code into the kernel, got it accepted, and then said nothing for two weeks as the bogus commit spread through the Linux development process and ended up in the stable tree, and, potentially, in forks.

Re: “They introduce kernel bugs on purpose”

#248

Earlier quoted context omitted.

If the IRB is any good the professor doesn't get that. Universities are publish or perish, and the IRB should force the withdrawal of all papers they submitted. This is might be enough to fire the professor with cause - including remove any tenure protection they might have - which means they get a bad reference. I hope we hear from the IRB in about a year stating exactly what happened. Real investigations of bad con…

See page 9 of the already published paper: https://raw.githubusercontent.com/QiushiWu/qiushiwu.github.i... > We send the emails to the Linux communityand seek their feedback. The experiment is not to blame any maintainers but to reveal issues in the process. The IRB of University of Minnesota reviewed the procedures of the experiment and determined that this is not human research. We obtained a formal IRB-exempt lett…

This is exactly what I would have said: this sort of research isn't 'human subjects research' and therefore is not covered by an IRB (whose job it is to prevent the university from legal risk, not to identify ethically dubious studies).

It is likely the professor involved here will be fired if they are pre-tenure, or sanctioned if post-tensure.

Re: “They introduce kernel bugs on purpose”

#249
post #105

I would check their ties to nation-state actors. In closed source, nobody would even check. Modern DevOps has essentially replaced manual code review with unit tests.

I don't understand why this isn't a more widely-held sentiment. There's been instance after instance of corporate espionage in Western companies involving Chinese actors in the past 2 decades.

Re: “They introduce kernel bugs on purpose”

#250
post #226

Earlier quoted context omitted.

Hearing how you phrased it reminds me of a study that showed how parachutes do not in fact save lives (the study was more to show the consequences of extrapolating data, so the result should not be taken seriously): https://www.bmj.com/content/363/bmj.k5094

This is now my second favourite paper after the atlantic salmon in fmri

link?
Post reply on HN