Live data from Hacker News

“They introduce kernel bugs on purpose”

lore.kernel.org

781–790 of 1001 posts

Re: “They introduce kernel bugs on purpose”

#781
post #253

Greg does not joke around: https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh... [PATCH 000/190] Revertion of all of the umn.edu commits

How does the kernel still run after reverting like this?

The answer is somewhere between "it's 'only' 190 patches" and "Greg posting this patch series doesn't mean it's applied to stable yet"

Re: “They introduce kernel bugs on purpose”

#783

Here's a clarification from the Researchers over at UMN[1]. They claim that none of the Bogus patches were merged to the Stable code line : >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 t…

I wonder why they didn't just ask in advance. Something like 'we would like to test your review process over the next 6 months and will inform you before a critical patch hits the users', might have been a win-win scenario.

Re: “They introduce kernel bugs on purpose”

#784
Let me play devil's advocate here. Such pen-testing is absolutely essential to the safety of our tech ecosystem. Countries like Russia, China and USA are without a doubt, doing exactly the same thing that this UMN professor is doing. Except that instead of writing a paper about it, they are going to abuse the vulnerabilities for their own nefarious purposes.

Conducting such pen-tests, and then publishing the results openly, helps raise awareness about the need to assume-bad-faith in all OSS contributions. If some random grad student was able to successfully inject 4 vulnerabilities before finally getting caught, I shudder to think how many vulnerabilities were successfully injected, and hidden, by various nation-states. In order to better protect ourselves from cyberwarfare, we need to be far more vigilant in maintaining OSS.

Ideally, such research projects should gain prior approval from the project maintainers. But even though they didn't, this paper is still a net-positive contribution to society, by highlighting the need to take security more seriously when accepting OSS patches.

Re: “They introduce kernel bugs on purpose”

#785
post #784

Let me play devil's advocate here. Such pen-testing is absolutely essential to the safety of our tech ecosystem. Countries like Russia, China and USA are without a doubt, doing exactly the same thing that this UMN professor is doing. Except that instead of writing a paper about it, they are going to abuse the vulnerabilities for their own nefarious purposes. Conducting such pen-tests, and then publishing the results…

Then do it through pen testing companies. Not official channels masquerading as research.

Re: “They introduce kernel bugs on purpose”

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

Instead of not being nice, maybe Linux should adopt some sort of CI and testing infrastructure.

https://kernelci.org is a Linux Foundation project; there are others, but that's just the main one I know of offhand.

The idea that "not being nice" is necessary is plainly ridiculous, but this post is pretty wild--effectively you're implying that they're just amateurs or something and that this is a novel idea nobody's considered, while billions and billions of dollars of business run atop Linux-powered systems.

What they don't do is hand over CI resources to randos submitting patches. That's why kernel developers receive and process those patches.

Re: “They introduce kernel bugs on purpose”

#790

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…

So, the patch was about a possible double-free, detected presumably from a bad static analyzer. Couldn't this patch have been done in good faith? That's not at all impossible.

However, the prior activity of submitting bad-faith code is indeed pretty shameful.

Post reply on HN