University Banned From Contributing To Linux Kernel For Intentionally Inserting Bugs

[moilami]

Even though no direct life danger happened because of this "research", this is still comparable to "research" on what happen in traffic if you sabotage various components in cars. Also, the window for free sabotages can not be open in the name of "research".

[oiaohm]

And these few injected bugs will tell substantially more about the state of the kernel than the bug reports received from all around the world, all the time? The fact that some method exists doesn't mean it makes sense in every context.

Its having exact count of faults injected and how many were detected give you detection rate information you don't have otherwise. I not say what they did was a good idea without correct backing of maintainers and so on to control the risks.

Even though no direct life danger happened because of this "research", this is still comparable to "research" on what happen in traffic if you sabotage various components in cars. Also, the window for free sabotages can not be open in the name of "research".

moilami in self driving cars Linux is used in different systems. So the idea that no direct life was in danger because of this research is a big mistake and why stunt like this can turn into mega sued very quickly as this is possible life endangering sabotage that could be a cause of death. Please note its not only cars where Linux kernel could be in critical systems so a missed bug intentionally injected slipping though does bring very big legal problems.

Windows is not free of sabotages either windows insider test versions do at times contain Bebugging process of adding faults. But these are time limit usage trial versions. Yes Microsoft collects a lot of data because they are performing research on those doing beta testing and end users.

[moilami]

Its having exact count of faults injected and how many were detected give you detection rate information you don't have otherwise. I not say what they did was a good idea without correct backing of maintainers and so on to control the risks.


moilami in self driving cars Linux is used in different systems. So the idea that no direct life was in danger because of this research is a big mistake and why stunt like this can turn into mega sued very quickly as this is possible life endangering sabotage that could be a cause of death. Please note its not only cars where Linux kernel could be in critical systems so a missed bug intentionally injected slipping though does bring very big legal problems.

Windows is not free of sabotages either windows insider test versions do at times contain Bebugging process of adding faults. But these are time limit usage trial versions. Yes Microsoft collects a lot of data because they are performing research on those doing beta testing and end users.

I know that stuff. But supposedly nothing has happened because of this research yet, which is not a reason to take it lightly. Linux devs has taken good strong actions and banned the whole university, so they clearly understand the seriousness of this case.

[SalJ163]

Leon Romanovsky claims to see intentional security bugs in 3 out of 4 patches he looked at.

They introduce kernel bugs on purpose. Yesterday, I took a look on 4 accepted patches from Aditya and 3 of them added various severity security "holes".

In regard to that university they seem to specifically mostly criticize the Aditya individual, who is unrelated to the research paper.
Al Viro explains some of the code by that individual does not seem to introduce bugs, but is bad code:

Look at the code immediately prior to the site of your "fix".
Think for a second what will happen if we *could* get there with rm
equal to NULL (with your patch applied, that is). Now, try to construct
the sequence of events that would lead to that situation. Either you
will arrive at a real bug (in which case your fix does not actually
fix anything) *OR* you will get closer to realization that "defensive
programming" tends to be worthless garbage. In both case the result
would be useful...

I found a few such examples where the patch added a test for pointer validity after the pointer was already dereferenced. It is useless code, but not introducing a bug.
I tried to find actual bugs, as alleged. The patches that looked questionable to me were instances of the already mentioned pointless code and one can argue that removing unnecessary BUG() check statements will make it easier in the future to introduce bad code.

Romanovsky gives this patch as an example for a supposedly intentional bugs.

you are invited to take a look on this patch that has "built-in bug": 8e949363f017 ("net: mlx5: Add a missing check on idr_find, free buf")

The code was reviewed by someone working for oracle and signed off by people working for the Linux kernel and Mellanox.
Not knowing how the called functions, like idr_find, look inside the code looks reasonable to me.

Though now that I looked closer at the file history the best I can come up with is that it made a bug that was already there more exploitable, because the next code change by the maintainers was to move a function that previously wasn't inside the read_lock into the read_lock. https://github.com/torvalds/linux/co...94c0c4620db6a2
The research paper talks about introducing concurrency problems by moving something out of a lock. In this case they moved something that was already outside of the lock and thereby reasonably should be possible to move.
Who knows. Maybe that user did genuinely make an effort to make Linux less secure with small, plausible, changes like that. Hard to tell. Considering the type of people in this forum unlikely, but if any of you find more convincing examples I'd like to see them.

I not say what they did was a good idea without correct backing of maintainers and so on to control the risks.

The authors of the research paper claim that none of their code made it into the kernel, because they contacted the maintainers afterwards.
They also outlined in their paper that it takes some time for a patch to get into the kernel, giving them enough time to contact the maintainers after they would have accepted the patch. If they genuinely did everything the way they outlined it in the paper it'd be not that bad. Contacting one of the lead developers in advance would have been better, but some people seem to think they had no plan at all.
Officially they committed 3 patches, none of which using a university email, none of which making it into the kernel.
If their patches with those gmail accounts are on one of the publicly visible mailing lists it would have been nice if they would have referenced those in the paper, since someone in the linux-nfs mailing list claims to have identified the two gmail accounts and one patch submitted by one of the accounts made it into the kernel.

[oiaohm]

The authors of the research paper claim that none of their code made it into the kernel, because they contacted the maintainers afterwards.

That absolutely not a good idea. You need to move something that would normally be illegal on the roads you contact the police in advance for approval. Same with kernel maintainers.

https://lore.kernel.org/linux-nfs/[email protected]/

The problem patches in current round are umn.edu accounts.

I found a few such examples where the patch added a test for pointer validity after the pointer was already dereferenced. It is useless code, but not introducing a bug.

The original research paper was done with some safe guards. That original paper documents about creating concurrency errors. The code being submit from umn.edu accounts this time matches the format research paper for creating faults. Either this is follow up research done by someone incompetent or someone is needing prosecution.

When you are attempt to cause concurrency errors what looks like useless code is not harmless if the compiler is not going to remove it as it add processing time so making a non exploitable concurrency error in code come exploitable by altering timings.

Yes who ever did the follow up research did not allow that maybe the Linux kernel maintainers were looking now for this kind of behaviour since they had been made aware of it. Yes the first time you might get away with not informing the maintainers first second round not going to be as lucky.

[indepe]

Because Greg intentionally ignored the text of the paper, or did what people these days like to do: read the title only and overreact, he now reverted almost 200 patches and they are yet to find one of those supposedly intentionally added bugs.
The reverted changes aren't even the type of account they are looking for. The research paper states "27% of the incorrect patches were made by fresh developers who have never touched the source code files before" and that they used accounts like that for their paper instead of university emails.

Re-reviewing for security isn't a bad idea, except in this case it seems to be wasting people's time (as long as I am not the people, I am OK with it), but this far there isn't a single malicious commit, instead they just reverted a lot of bug fixes that they'll need to add one-by-one.
The real issue Greg got upset about is that someone (unrelated to the paper) posted low quality code, suspected to be from a static analyzer, with a university account and he thinks it's some social experiment by one of the professors.

He didn't "ignore the text of the paper". This isn't about the handful of patches directly mentioned in the paper. It is about the many other changes coming from roughly the same direction, that didn't make sense as good-faith changes. He didn't buy the excuse of using a newly written static ananlyzer. (And isn't it necessary to competently confirm the results of such an apparently experimental analyzer before submitting changes based on them to the official Linux kernel?) In the light of the previously published paper, the intention didn't seem to be any better, mostly mentioning the apparently obvious (once one takes a closer look) "useless" -ness of the code (which due to the previous research paper also raised questions about the security impact).

Either way, the kernel isn't a playground for such research or anyone following in the footsteps of such research, or even for bad experimental static analyzers. A stop had to be put to that, at least until there is more clarity about the nature of those 200+ changes. And what all that had in common was (apparently) the general direction it came from.

[Guest]

This is an immature and unprofessional move by Greg KH. Ban specific email addresses sure, but banning an entire University of students, professors and researchers is just idiotic.

[S.Pam]

This is an immature and unprofessional move by Greg KH. Ban specific email addresses sure, but banning an entire University of students, professors and researchers is just idiotic.

Not really. It's about containing possible faults. When you don't know the exact population/number of bad parts/code you need to isolate a much larger number to be on the safe side. Then you go through quality control again and determine what to keep, drop or add.

Example: A car manufacturer found a bad part from a supplier and now need to isolate the possible batches of cars that could be affected. However
, because the supplier didn't have good track of their production they could only say the problem was likely introduced within the last few. As a consequence the car manufacturer have to recall a really large number of batches to ensure there were no faults unaccounted for.

[oiaohm]

This is an immature and unprofessional move by Greg KH. Ban specific email addresses sure, but banning an entire University of students, professors and researchers is just idiotic.

The world is not fair. Greg KH move here is not unprofessional. You have the original paper that put in 3 patches that had to be fixed up that was done in a unsafe way. Yes formal complaint was done over the first paper because it was unsafe. Now there are 200+ more patches from that university that are crap.

University students are meant to have proper supervision. The Linux kernel due to how many critical things depend on the Linux kernel means its not a playground.

The hard reality here is not Greg KH who should have block a University email account. Yes correct action in this case is really block the university and wait for the university final report that may be the student kicked out of their course or someone else punished for poor supervision. This will send a clear message Linux kernel is absolutely not a playground for experimental crap.

Really how many more cases of bad supervision has to be let slide. Hard reality here a University as a whole is responsible for the actions of their students and is responsible to punish those students or refer them for criminal charges in cases like this. Until the university deals with the problem cutting them off is the correct action as this is the second time. First time formal complaint second time complete block is justified. Third time the legal departments of the companies supporting Linux will get involved.

There is a form of a 3 strike rule here except each strike from the Linux Foundation/Linux Kernel gets harder each hit for organisations wishing to submit code..
1) Warning to your organisation about dangerous coding behaviour.
2) Ban of all submits by your organisation.
3) Legal actions by the other organisations that work on the Linux kernel in good faith.

sandy8925 why should the University got special treatment the first paper they got strike 1. They are now on strike 2. That 3 step policy of the Linux kernel has been in place for over 20 years. Linux kernel is not the place careless messing around.

People wonder why there are not more attempts to put exploits in the Linux kernel anyone who has read what the response policy is will normally not do it particularly when you work out its a strike 3 is a few thousand multi nationals after your hide backed up by many governments. The progressively getting worse until you are bankrupt. Lot of ways intentionally adding an exploit to the Linux kernel is way more dangerous for you than working at Microsoft and adding an exploit intentionally to windows. Microsoft with windows will want to cover up to the public that it happened. Linux kernel since the source code is public the fact its happen is on the record now companies want their pound of flesh from next to you heart.

[indepe]

AFAIC reviews find that most of the patches from the general email domain are valid fixes, and a smaller number just useless, while the number of really problematic ones is much, much smaller than 200. Yet it seems to include one from one of the authors of the paper, and patches from his own student(s).