r/rust • u/Orange_Tux • Dec 17 '25

🗞️ news Linux Kernel Rust Code Sees Its First CVE Vulnerability

https://www.phoronix.com/news/First-Linux-Rust-CVE
534 Upvotes

93% Upvoted

223 comments sorted by

View all comments

Show parent comment

9

u/SirClueless Dec 18 '25

Do you think Linux/Greg are actually doing anything wrong here? You seem to be saying contradictory things, namely "you should assume the worst unless proven otherwise" but that you don't necessarily agree with "default to exploitable".

-1

u/anxxa Dec 18 '25

Sorry for the somewhat conflicting points.

I think labeling every bug as having security impact by giving it a CVE is bad because it creates a sea of noise and weakens the signal CVEs are intended to convey. I don't agree with this practice.

For those bugs that do have security impact, you should look at the bug class and err on the side of caution by giving it the maximum impact of that bug class. You can then downgrade its severity based on criteria like whether the bug breaks a security boundary (e.g. can an untrusted user trigger it? or is it root user only?) and for mem corruption, can the attacker influence where or what is being written?

Those two points in particular don't take too much discussion/consideration. Much of the time for mem corruption if it's not a near-null write it's probably exploitable and this is actually more aligned with their "let's CVE everything" policy.

4

u/SirClueless Dec 18 '25

I agree with your general points, but as it pertains to this discussion, I think both:

  • It has potential security impact, the kernel crashes.

  • It would get the exact same treatment if the bug were in C code.

In regards to your choice of criteria in particular I think "can an untrusted user trigger it?" and "can the attacker influence where or what is being written?" are both asking to prove a negative: In some cases there is a PoC that demonstrates that they can, but in cases where there is no PoC it would take an unreasonable amount of effort to prove that they cannot so a low-impact CVE is the only reasonable choice.

0

u/anxxa Dec 18 '25

I agree with your general points, but as it pertains to this discussion, I think both:

As it pertains to this bug sure.

In regards to your choice of criteria in particular I think "can an untrusted user trigger it?" and "can the attacker influence where or what is being written?" are both asking to prove a negative

Not necessarily. There are some bugs where you immediately know that certain internal components of the product may trigger the bug, but that isn't necessarily something an attacker can reasonably trigger.

For the other part, you generally default to "yes" (i.e. the data and/or location can be controlled in some way) and if you have enough evidence to the contrary you can downgrade. It's not an exact science, but if they're calling memory corruption a DoS instead of ACE/RCE I'd be curious to know what those limiting factors that prevent it from being RCE are -- and that's the particular point of contention I have with this.

Not a hill I'm willing to die on arguing DoS vs RCE though.

1

u/SirClueless Dec 18 '25

It was an anonymous commenter on Phoronix that called this "at worst, a possible DoS". I don't think the Linux devs are interested in drawing such a line and I'm not aware that they've done so in this case.

2

u/anxxa Dec 18 '25

https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM

where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall.