| ▲ | tptacek 6 hours ago |
| From their perspective, on their project, with the constraints they operate under, bugs are just bugs. You're free to operationalize some other taxonomy of bugs in your organization; I certainly wouldn't run with "bugs are just bugs" in mine (security bugs are distinctive in that they're paired implicitly with adversaries). To complicate matters further, it's not as if you could rely on any more "sophisticated" taxonomy from the Linux kernel team, because they're not the originators of most Linux kernel security findings, and not all the actual originators are benevolent. |
|
| ▲ | rwmj 6 hours ago | parent | next [-] |
| For sure, but you don't need to file CVEs for every regular bug. |
| |
| ▲ | Skunkleton 5 hours ago | parent [-] | | In the context of the kernel, it’s hard to say when that’s true. It’s very easy to fix some bug that resulted in a kernel crash without considering that it could possibly be part of some complex exploit chain. Basically any bug could be considered a security bug. | | |
| ▲ | SSLy 5 hours ago | parent [-] | | plainly, crash = DoS = security issue = CVE. QED. | | |
| ▲ | michaelt 4 hours ago | parent | next [-] | | BRB, raising a CVE complaining the OOM killer exists. | | |
| ▲ | pamcake 3 hours ago | parent | next [-] | | Memory leaks are usually (accurately) treated as DoS. OoM killer is a mitigation to contain them and not DoS the entire OS. | |
| ▲ | worthless-trash an hour ago | parent | prev [-] | | I could be wrong. But operation by design isn't considered a bug. | | |
| |
| ▲ | 5 hours ago | parent | prev [-] | | [deleted] |
|
|
|
|
| ▲ | JCattheATM 5 hours ago | parent | prev [-] |
| > From their perspective, on their project, with the constraints they operate under, bugs are just bugs. That's a pretty poor justification. Their perspective is wrong, and their constraints don't prevent them from treating security bugs differently as they should. |
| |
| ▲ | ada0000 5 hours ago | parent [-] | | > almost any bugfix at the level of an operating system kernel can be a “security issue” given the issues involved (memory leaks, denial of service, information leaks, etc.) On the level of the Linux kernel, this does seem convincing. There is no shared user space on Linux where you know how each component will react/recover in the face of unexpected kernel behaviour, and no SKUs targeting specific use cases in which e.g. a denial of service might be a worse issue than on desktop. I guess CVEs provide some of this classification, but they seem to cause drama amongst kernel people. |
|