I'm not sure I agree with this conclusion. It does seem the linux kernel is at high risk of being exploited just because the payoff is so large. Perhaps not in a way as obvious as previous...
Another lesson is something we already knew: kernel maintainers (and maintainers of many other free-software projects) are overworked and do not have the time to properly review every patch that passes through their hands. They are, as a result, forced to rely on the trustworthiness of the developers who submit patches to them. The kernel development process is, arguably, barely sustainable when that trust is well placed; it will not hold together if incoming patches cannot, in general, be trusted.
One final lesson that one might be tempted to take is that the kernel is running a terrible risk of malicious patches inserted by actors with rather more skill and resources than the UMN researchers have shown. That could be, but the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more.
I'm not sure I agree with this conclusion. It does seem the linux kernel is at high risk of being exploited just because the payoff is so large. Perhaps not in a way as obvious as previous attempts but at this point I would be more surprised if more sophisticated actors don't have malicious kernel commits in the wild.
For those 42 patches, the reasoning behind the revert varies from one to the next. In some cases, the patches apply to old and presumably unused drivers and nobody can be bothered to properly review them.
Also, this seems a problematic approach. I guess it depends on the drivers in question but 'presumably unused' seems like a strong statement to make for something that is most likely is a non-malicious commit that happens to be from a umn.edu address.
I'm not sure I agree with this conclusion. It does seem the linux kernel is at high risk of being exploited just because the payoff is so large. Perhaps not in a way as obvious as previous attempts but at this point I would be more surprised if more sophisticated actors don't have malicious kernel commits in the wild.
Also, this seems a problematic approach. I guess it depends on the drivers in question but 'presumably unused' seems like a strong statement to make for something that is most likely is a non-malicious commit that happens to be from a umn.edu address.