Comment by staticassertion
4 days ago
"A bug is a bug" lol.
There's a massive difference between "DoS requiring root" and "I can own you from an unprivileged user with one system call". You can say "but that DoS could have been a privesc! We don't know!" but no one is arguing otherwise? The point is that we do know the impact of some bugs is strictly a superset of other bugs, and when those bugs give control or allow a violation of a defined security boundary, those are security bugs.
This has all been explained to Greg for decades, nothing will change so it's just best to accept the state - I'm glad it's been documented clearly.
Know this - your kernel is not patched unless you run the absolute latest version. CVEs are discouraged, vuln fixes are obfuscated, and you should operate under that knowledge.
Attackers know how to watch the commit log for these hidden fixes btw, it's not that hard.
edit: Years later and I'm still rate limited so I can't reply. @dang can this be fixed? I was rate limited for posting about Go like... years ago.
To the person who replies to me:
> This is correct for a lot of different software, probably most of it. Why is this a point that needs to be made?
That's not true at all. You can know if you're patched for any software that discloses vulnerabilities by checking if your release is up to date. That is not true of Linux, by policy, hence this entire post by Greg and the talks he's given about suggesting you run rolling releases.
Sorry but it's too annoying to reply further with this rate limiting, so I'll be unable to defend my points.
> Know this - your kernel is not patched unless you run the absolute latest version.
This is correct for a lot of different software, probably most of it. Why is this a point that needs to be made?
(Parent has already replied by editing their original comment, but I'll tack on a bit more info, from my perspective.)
The reason this has to be emphasized is that all new code runs the risk of regressions, and in a production environment, you hate regressions. Therefore, not only do you not want new features, but you also don't want irrelevant bug fixes. Bug fixes, even security fixes, are not magically free of independent regressions. Therefore a valid incentive exists to minimize backports to production environments. And such a balancing act depends on the careful investigation of the impact of known bugs, one by one.
From the fine blog post:
> For those that are always worried “what if a bugfix causes problems”, they should remember that a fix for a known bug is better than the potential of a fix causing a future problem as future problems, when found, will be fixed then.
A whole lot of users can disagree with this. For good, practical reasons. The expected damage of a known bug may be estimated, while an unknown regression brought in by the fix for the known bug may cause way worse damage.