In general, the Linux kernel does not assign a CVE when fixing a security vulnerability. That's the case for most open source projects. It's important to use the latest revision of LTS branches and apply more fixes on top of that. Other than that there aren't really good answers.
Conversation
The newer kernel branches have lots of new vulnerabilities and attack surface. It's not clear if vulnerabilities are even being fixed at a faster rate than they're being added. Similarly, it's unclear if ongoing hardening work outweighs endless new attack surface / complexity.
1
3
10
I've talked about these issues a lot, and in a lot of depth. I recommend watching this talk to help with understanding the scale of the issues and the sorry state of software engineering not just in the Linux kernel but most other major software projects:
youtube.com/watch?v=qrBVXx
1
5
13
The Linux kernel uses a fundamentally insecure architecture, insecure tools, and has a development culture treating correctness and especially security as an afterthought. It ultimately needs to replaced, but until then, best effort approaches minimizing the harm are important.
2
9
16
This Tweet is from a suspended account. Learn more
Replying to
The Linux kernel and other fundamentally insecure software projects designed and implemented without robustness and security as core principles. The Linux kernel is likely getting less secure over time, not more secure, and there is no feasible way to fix a problem of this scale.
2
5
7
Replying to
Almost entirely security theater with no real impact. Not relevant in any way to solving these kinds of problems or mitigating kernel vulnerabilities. It's based around providing a bogus, incomplete form of secure boot not actually providing any real security value to end users.
1
1
It's a marketing-focused, incomplete and useless approach to secure boot. The total value of it is negligible and it's very unfortunate that it's all grouped together as part of something that's almost completely nonsense with no real threat model or use case thought out for it.
1
1
Replying to
I've complained a lot about this patch series and the marketing-based nonsense approach to secure boot motivating it. Unfortunately, that fell on deaf ears, and in the end security theater is what triumphs. It's part of the general problem with the Linux approach to "security".
Security and privacy features need to have a clear threat model and practical purpose, or they do more harm than good by layering on even more complexity and permanently taking away complexity budget / resources from meaningful work. This whole thing didn't make much sense.
1
1
2
Secure boot that only protects firmware and the kernel doesn't make any sense. The kernel doesn't do anything useful by itself. Also, treating the kernel boundary this way is *extremely* harmful in terms of being able to reduce kernel attack surface and move complexity out of it.
1
1
Show replies