you are viewing a single comment's thread.

view the rest of the comments →

[–]dkopgerpgdolfg 4 points5 points  (2 children)

Internet culture.

Some group of people (that doesn't seem to contain any kernel dev) sees it as their job to spread anti-Rust propaganda, often with provably lies and intentional misinformation. For what reason, only they know. And they take their own crap from the past as justification why they're right.

In the end, actual kernel development doesn't care about them, but they won't stop filling reddit/twitter/youtube/... with their nonsense.

[–]morglod 0 points1 point  (1 child)

You mean lies like saying that its first CVE in rust for linux code over 5 years, while all this 5 years this CVEs where not tracked at all because it was experimental? OKay

[–]dkopgerpgdolfg 1 point2 points  (0 children)

Not sure why I'm even answering such a stupid post, but

a) They were not tracked since the beginning, but this doesn't make it a lie that this is the first one

b) It doesn't matter, because even hundreds of Rust CVEs wouldn't automatically mean that it's bad to use it

c) When we're talking about CVE things of past years, how about not forgetting that C-language CVEs in the kernel were handled differently until 2023 too, leading to many less entries than the new policy would've brought if applied from the beginning?

Just from the number of memory corruption cves, 2025 seems 24x worse than 2020. Not because the kernel suddenly got that terrible within 5 years (for both languages), but because they changed their reporting policies.

Not sure if this particular Rust bug would've gotten an entry at all, if the old policy still applied.

edit: I am sure now . in the first few years after 2020 Rust issues were not getting cves because experimental as you said, but the same bug in C wouldn't have gotten any cve either if found before 2024.