Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

501–510 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#501
post #343
post #286

How is such a ban going to be effective? The "researchers" could easily continue their experiments using different credentials, right?

Arbitrary anonymous submissions don't go into the kernel in general. The point[1] behind the Signed-off-by line is to associate a physical human being with real contact information with the change. One of the reason this worked is likely that submissions from large US research universities get a "presumptive good faith" pass. A small company in the PRC, for an example, might see more intensive review. But given the h…

They do if the patch "looks good" to the right people.

In late January I submitted a patch with no prior contributions, and it was pushed to drm-misc-next within an hour. It's now filtered it's way through drm-next and will likely land in 5.13.

Re: “They introduce kernel bugs on purpose”

#502
post #360

I don't like this university ban approach. Universities are places with lots of different students, professors, and different people with different ideas, and inevitably people who make bad choices. Universities don't often act with a single purpose or intent. That's what makes them interesting. Prone to failure and bad ideas, but also new ideas that you can't do at corporate HQ because you've got a CEO breathing dow…

> The people banned didn't do anything wrong. There are ways to do research like this (involve top-level maintainers, prevent patches going further upstream etc.), just sending in buggy code on purpose, then lying about where it came from, is not the way. It very much is wrong in my opinion. And like some other people pointed out, it could quite possibly be a criminal offense in several jurisdictions.

>There are ways to do research like this (involve top-level maintainers, prevent patches going further upstream etc.)

This is what I can't grok. Why would you not contact GKH and work together to put a process in place to do this in an ethical and safe manner? If nothing else, it is just basic courtesy.

There is perhaps some merit to better understanding and avoiding the introduction of security flaws but this was not the way to do it. Boggles the mind that this group felt that this was appropriate behavior. Disappointing.

As far as banning the University, that is precisely the right action. This will force the institution to respond. UMN will have to make changes to address the issue and then the ban can be lifted. It is really the only effective response the maintainers have available to them.

Re: “They introduce kernel bugs on purpose”

#503

I did my Ph.D in cognitive neuroscience, where I conducted experiments on human subjects. Running these kinds of experiments required approval from an ethics committee, which for all their faults (and there are many), are quite good at catching this kind of shenanigans. Is there not some sort of equivalent in this field?

It seems they lied to the ethics committee. But I'm not holding my breath for the University to sanction them or withdraw/EoC their papers, because Universities prefer to have these things swept under the carpet.

Re: “They introduce kernel bugs on purpose”

#504
post #365

I still don't get the point of this "research". You're just testing the review ability of particular Linux kernel maintainers at a particular point in time. How does that generalize to the extent needed for it to be valid research on open source software development in general? You would need to run this "experiment" hundreds or thousands of times across most major open source projects.

The Linux kernel is one of the largest open-source projects in existence, so my guess is that they were aiming to show that "because the Linux kernel review process doesn't protect against these attacks, most open-source project will also be vulnerable" - "the best can't stop it, so neither will the rest".

But we have always known that someone with sufficient cleverness may be able to slip vulnerabilities past reviewers of whatever project.

Exactly how clever? That varies from reviewer to reviewer.

There will be large projects, with many people that review the code, which will not catch sufficiently clever vulnerabilities. There will be small projects with a single maintainer that will catch just about anything.

There is a spectrum. Without conducting a wide-scale (and unethical) survey with a carefully calibrated scale of cleverness for vulnerabilities, I don't see how this is useful research.

Re: “They introduce kernel bugs on purpose”

#505

Wow this "researcher" is a complete disaster. Who nurtures such a toxic attitude of entitlement and disregard for others time and resources? Not to mention the possible real world consequences of introducing bugs into this OS. He and his group need to be brought before an IRB.

Victim mentality is being cultivated on campuses all over the US. This will not be the last incident like this.

Re: “They introduce kernel bugs on purpose”

#506

They should be reported to the authorities for attempting to introduce security vulnerabilities into software intentionally. This is not ok.

I'm a PhD student myself. What he did is not okay! We study computer science to do good not to harm.

Re: “They introduce kernel bugs on purpose”

#507
post #413

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 kerne…

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.

Re: “They introduce kernel bugs on purpose”

#508
post #342

> I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts. Maybe not being nice is part of the immune system of open source.

Not being nice is always to protect self. Not always effective though, and not always necessary.

Re: “They introduce kernel bugs on purpose”

#509

Me thinks that If you hold a degree from the University of Minnesota it would be a good idea to let your university know what you think of this.

I'm trying to figure out how to do that. How can I get my degree changed? Will the university of (anyplace) look at my transcript and let me say I have a degree from them without much effort? I learned a lot, and I generally think my degree is about as good as any other university. (though who knows what has changed since then) I'm glad I never contributed again as an alumni...

If it would be my univ, I'd send a personal email to the dean. https://cse.umn.edu/college/office-dean#:~:text=Dean%20Mosta....

If enough grads do that, I would expect the university will do something about it, and that would send a message. It's about where the money comes from in the end; (tuition, grants, research partnerships etc) IMO none of these sources would be very happy about what might amount to defacement of public property and waste of the time of people that are working for the good of mankind by providing free tools(bicycle of the mind) to future generations.

There is no novelty in this research; bad actors have been trying to introduce bad patches for as long as open source has been open.

Re: “They introduce kernel bugs on purpose”

#510
post #342

> I will not be sending any more patches due to the attitude that is not only unwelcome but also intimidating to newbies and non experts. Maybe not being nice is part of the immune system of open source.

Attacking those critical of your questionable behavior and then refusing to participate further is a common response people have when caught red handed.

This is just a form of "well I'll just take my business elsewhere!". Chances are he'll try again under a pseudonym.

Post reply on HN