Dear Linux Kernel CNA, what have you done?

Having a large number of new, unscored, CVEs in the Linux kernel is going to make things... interesting. From their lists https://lore.kernel.org/linux-cve-announce/ these just have a CVE and not really enough detail for anyone to assign a score without a lot of additional analysis, which reduces their usefulness.

To an extent it could be suggested they're just exposing an existing flaw in the system (CVSS scores which may be taken to be scientifically applied, are actually just matters of opinion in many cases), but it will cause a lot of problems with automated tooling and compliance.

Shouldn't this strategy lead to the opposite? By being overly cautious they should only assign CVEs for real demonstrable security issues.

The environment where we write critical code the way we do now is very wrong. It's actually not that easy to figure out if something is exploitable or not. What if you add heap grooming? What if you enable another specific feature? What if an application fights for the same lock? What if measuring the time it takes to fail allows you to defeat aslr? People use exploit chains rather than independent ones these days and there are examples of clever cases of single-byte overflows turning into RCE.

Sure, there are going to be cases where you're really really sure something can't be used, because for example the bug only produces a null dereference and an oops. Then someone else comes along and proves you wrong https://googleprojectzero.blogspot.com/2023/01/exploiting-nu...

Being cautious here means "it's better to assign a CVE when it's not a vulnerability, than to NOT assign a CVE when it's actually a vulnerability"

Then the correct approach is not to cause "CVE fatigue" that can cause significant second-order effects. Not to mention the fact that who else is better suited to make that assessment? It's unavoidable that an assessment still has to be made because fundamentally there are use-cases where touching a working system has to have a really good reason. This will result in actually important things not getting patched because not-kernel-experts had to make that decision.

I also can't imagine large vendors being forced to follow a significantly more frequent update cadence also choosing to retain their current level of QA. Best case we're going to get more frequent less tested updates, worst case we're going to deploy an actual vulnerability due to some low-importance bugfix (with an assigned CVE).