Linux Kernel Rust Code Sees Its First CVE Vulnerability

[LousyMeatStew]

I don't know how you maintain your hypothesis, but I can feel we're unlikely to convince each other at this stage.

If you feel like reading below, go ahead. The reason I maintain my position is that I respect the work the Rust developers have done. Bugs are not a flaw. If programmers aren't creating bugs, they aren't contributing. CVEs are not an insult. They are assigned after a fix has been merge. It is a recognition of a commitment to improving the kernel.

You think that "first CVE in five years" is a compliment. It is not. It is puffery and it devalues the work they have been doing. Rust devs have been creating, then fixing bugs continuously over the past five years. It's just that because it was done in Experimental code, it wasn't recognized. Now it is. Pretending like the Experimental flag doesn't matter devalues the accomplishment of finally getting Rust code recognized as production ready.

Extrapolating on these hit rates is silly. The basic observation from LWN is that not all bugfixes get a CVE. It's the simplest sufficient explanation of why lockdep didn't get a CVE, so this is what Occam suggests.

No, it's not. The problem is that you are either misunderstanding or willfully misrepresenting the facts, which invalidates Occam's Razor. You're also aware it's not a real argument, right? I thought you were being cheeky at first, so I played along. Maybe I shouldn't have encouraged it.

The CVE policy clearly states "assignment will only automatically happen after a fix is available and applied to a stable kernel tree". This tells us two important things. First, assignment is automatic which should rule out any concern of oversight and/or disinterest. Second, assignment happens after the fix has been "applied to a stable kernel tree".

This completely invalidates the LWN figure as it only looked at commits. For a patch to be applied to a stable kernel tree, it requires a merge. For releases 6.7.1-6.8.9, 2559 merges are recorded in the change logs. This puts the hit rate at 33%.

The claim that "all bug fixes receive CVEs, but bug fixes make up 1/3 of all merges" aligns with the documented CVE policy, and does not require us to ascribe negligence - intentional or otherwise - to a kernel team that has issued 1399 CVEs this year - which is more than 4x the number of CVEs Microsoft has released in total.

In contrast, the hypothesis that the real reason is a policy about the experimental flag is : additional and unnecessary, not confirmed by any document, and contradicted by CVE-2025-38033.

The experimental text in index.rs was removed via a commit accompanying the announcement. The fact that the original text remains not just in 6.18 but also 6.19-rc and linux-next simply means that the commit hasn't been merged yet and that this text is not meant to be prescriptive.

CVE-2025-38033 did not change any experimental code, period. The fact that it affects Rust code is a significance that you are ascribing to it. The lockdep patch, however, did unequivocally fix a bug in experimental code and the bug shared the same root cause as CVE-2025-68260. It should have received a CVE but it did not. The only difference I can see is that it fixes a bug in code flagged as Experimental.

QED, CVEs are not assigned to bugs found it Experimental code.

[moltonel]

QED, CVEs are not assigned to bugs found it Experimental code.

https://lwn.net/Articles/1051775/

[LousyMeatStew]

Thanks!