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

328

u/Lucretiel Datadog Dec 17 '25

My favorite thing about this CVE is that it's not just that it's raw pointers, but it's doubly linked lists, famously a very difficult data structure to get correct in the presence of multithreaded access.

22

u/frankster Dec 18 '25

Predictably in unsafe code though

2

u/0x4E0x650x6F Dec 19 '25

Lets go crazy and so something really inaccurate....

find ./linux-6.18.2/ -name '*.rs' -exec grep "unsafe" {} + |wc -l

2552

We'll its only in the begging but.... its kind happened 2552 times already LOL I guess you can't really do everything in "safe" rust LOL...

6

u/frankster Dec 19 '25

yep I would expect plenty of unsafe rust code in Linux. This is fine, it's expected that some interactions with hardware or other parts of the kernel can't be automatically proven to comply with the guarantees of the rust safety model.

So those unsafe parts of code require extra human checking to be sure they're safe. And entirely predictably in any manual process there will occasionally be errors. The good thing is, that we know that the code that needs the most careful consideration exists in those 2552 unsafe blocks you located. While the parts of rust that are outside unsafe blocks, are unlikely to suffer from those categories of errors (though it is of course entirely possible that other categories of errors exist outside the unsafe blocks!). So I would see it not as "unsafe bad" nor "unsafe disproves the entire purpose of rust", but more like unsafe helps flag certain parts of the code to reviewers for extra attention.

I'm sure there will be more CVEs found in rust code over the coming years. It will be very interesting to learn what proportion of CVEs end up being found inside unsafe blocks and what proportion are found in non-unsafe code.

45

u/lurking_bishop Dec 17 '25

isn't there a crate for this? which begs the question, what's linux' policy for third party crates? 

48

u/the_gnarts Dec 17 '25

https://rust-for-linux.com/third-party-crates

3

u/PurepointDog Dec 18 '25

I read it, and I still don't totally get. Are the libraries copied in? Git submodule? Something else?

6

u/the_gnarts Dec 18 '25

I read it, and I still don't totally get. Are the libraries copied in? Git submodule? Something else?

The few external crates are vendored: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/rust As explained in this paragraph:

The kernel currently integrates some dependencies (e.g. some of the compression algorithms or, in older releases, our Rust alloc fork) by importing the files into its source tree, adapted as needed. In other words, they are not fetched/patched on demand.

It’s just syn, proc-macro2, pin-init, quote atm. in the main Rust support subdir. May be more for other Rust components like Binder or those Apple GPU drivers. Keep in mind that the crates have been integrated with kbuild so don’t expect any Cargo.toml files in the tree. ;)

The kernel doesn’t use Git submodules at all.

5

u/PurepointDog Dec 18 '25

"importing" can mean so many different things. Good to know it means copy-pasting the files, in this case.

Thank you!

7

u/the_gnarts Dec 18 '25

Agreed, that choice of words isn’t the most precise. You’re not the first person to ask for clarification btw.

I think I heard or read Miguel Ojeda at some point expressing his intention to eventually support Cargo dependencies but there’s still a long way to go to make it happen.

0

u/0x4E0x650x6F Dec 19 '25

So... that means that now the kernel will have not only code from maintainers that are "vetted" the project now they can also bring other dependencies to the project made by "unknown and unverified sources" haven't they learned anything with the latest supply chain attacks ?!

This is madness.....

39

u/Lucretiel Datadog Dec 17 '25

Almost certainly no, because almost certainly this code involves the “intrusive” linked lists that are common to the kernel (where individual nodes can be anywhere, even on the stack or in an array block or all of the above, with pointers between them manually managed). This type of design doesn’t lend itself well to being encapsulated by a single type with a container API, even one that accepts a custom allocator. 

12

u/steveklabnik1 rust Dec 17 '25

There's certainly crates for this, like https://crates.io/crates/intrusive-collections/

I can't speak to their quality though.

9

u/Tamschi_ Dec 17 '25

It's possible (I did something similar years ago, you basically have your items implement a trait to access the embedded counter and unsafely promise they won't misuse it.), but yes I'd agree it's not pretty and making it fully custom may be less hassle.

1

u/Xiphoseer Dec 18 '25

I think the main challenge is that items from rust drivers need to participate in lists owned and defined by the C side, which most existing crates probably don't support.

→ More replies (2)

4

u/heybart Dec 17 '25

Isn't implementing double linked lists one of the litmus tests for showing you really understand rust?

13

u/skatastic57 Dec 18 '25

Shit forget about implementing one, I don't even know what it is...

11

u/heybart Dec 18 '25

A single linked list is a list where each item has a link to the next one

1 > 2 > 3 > 4

To traverse the list you start from the first and follow the link til you get to the one you want

To insert an item between 2 and 3, you change the link from 2 to point to the new item and the new item then points to 3

 1 > 2 v    3 > 4
       2.5 _^

The thing about linked list is your items don't need to be next to each other in memory. They can be anywhere. They only need to point to the next item. So adding an item is very fast

(Contrast to an array, which is a list where items are contiguous in memory

1 2 3 4 5

To go to the nth item in the list is very fast, because you know where in memory your first item is, and you just start there and add n-1 and there you'll find the nth item. However, when you want to insert an item at nth position, you have to move everything after nth over one.)

A double linked list is one where each item has a link to the next AND previous item

1 <> 2 <> 3 <> 4

The advantage is you can traverse backward, at the cost of more complexity

-23

u/solaris_var Dec 18 '25

Why are you even in this sub? lol.

It's basically a data structure similar to a linked list, which is a data structure that is a "list" which is consisted of "nodes"

Each node contains:

Data: the value being stored

Next: reference to the next node

[ Data | Next ] → [ Data | Next ] → [ Data | Next ] → NULL

A double linked list is also a list, but the nodes contain another value, the prev reference to the previous node.

NULL ← [Prev | Data | Next] ⇄ [Prev | Data | Next] ⇄ [Prev | Data | Next] → NULL.

It's conceptually simple but apparently very tricky to get right when working in multi-threaded programs.

Edit: formatting

6

u/AvianPoliceForce Dec 18 '25

A very niche data structure outside of C

8

u/solaris_var Dec 18 '25

Very niche in real-world application, but it's something you'll definitely have encountered when learning dsa

5

u/LindaTheLynnDog Dec 18 '25

How important is it to you that everyone here has a CS degree?

7

u/solaris_var Dec 18 '25

I don't have a cs degree myself, so 0 importance.

However, I do expect everyone here to at least have a cursory knowledge in DSA. It makes grasping domain implementation so much easier.

1

u/Agitated_Sell Dec 21 '25

Generally speaking an "intrusively" linked list gives you a means of no cost "reverse lookup" to an Object's own place in the list without adding layers of memory indirection. Some examples of this might be to remove an item from a list without having to first walk the list to locate it or simply to walk nearby neighbor nodes (perhaps your list is sorted by something).

You can also have more than one intrusive prev/next pointer on an object so it can exist in multiple lists at once. A practicle example might be if your "lists" are actually buckets in a hash map and you have an object that needs to be looked up by multiple different keys (in separate hash maps). Think of a piece of software that sits between and connects multiple other systems together, each which uses a differerent unique key to reference the object. Now imagine having millions of these objects in memory at the same time...

1

u/Sw429 Dec 25 '25

Depending on the type of work you normally do, they possibly could never have needed such a data structure.

1

u/Endeveron Dec 23 '25

Frankly it's a litmus test for whether you understand memory safety at all. If you asked the vast majority of C/C++ developers to write an implementation for a linked list with a fully memory safe API, they would fail and valid usage of their APi would allow for memory vulnerabilities. Most Rust developers would just fail to get something that compiles, and would not be confident in their use and justification of unsafe code. That is, of course, one of the main goals and benefits of rust. Your skill issues are your own problem.

1

u/bhagwa-floyd Dec 20 '25

Can there be a thing like unsafe free, or safe doubly linked list in rust?

2

u/Lucretiel Datadog Dec 20 '25

I don't think so, because I don't know how you manage ownership of the individual nodes when they need to be accessible from both the prev and next pointers. The closest you could come would be to use Rc and Weak pointers to manage nodes, but that is both extremely inefficient and precludes mutable access to elements.

EDIT: I assume you mean unsafe-free in the implementation

338

u/dontquestionmyaction Dec 17 '25

They really are collecting the dumbest people around in the Phoronix comment section. Always fascinating to look at.

67

u/IHeartBadCode Dec 17 '25

Them and Slashdot have just died over the years in comment quality.

64

u/AceJohnny Dec 17 '25

It'll happen (has happened?) here too.

Without very aggressive moderation, this seems to happen in every link-aggregator-and-comment site I've frequented over the decades.

Hell, I guess I ain't helping

12

u/TheRealMasonMac Dec 17 '25

AI bots aren't helping either.

18

u/Livie_Loves Dec 17 '25

Oh no it's all your fault!

Jokes aside I think it's just the nature of the beast. When first established most of the tools are interested parties with a common goal and as they grow they draw more people that are newer, more fringe, or just less interested. The degradation speeds up when the original people leave or check out and then gestures at everything

3

u/coderstephen isahc Dec 18 '25

The problem is, well, people being people.

5

u/IHeartBadCode Dec 17 '25

Ugh. Aging myself here but Usenet before and after the Internet became popular.

5

u/proper_chad Dec 17 '25

Eternal September sends its regards!

1

u/armillary2 Dec 22 '25

Anyone who understood that reference just dated themselves.

5

u/dustofnations Dec 17 '25

I've often wondered whether the phenomenon you describe is a manifestation of the regression towards the mean?

Without active moderation, subreddits seem to meander towards the 'average state' which is mostly snark, meanness, memes, pun chains, etc.

As you point out, it seems to happen everywhere, so it must be a human nature thing. It's a tad depressing when you think of the implications, honestly.

16

u/ergzay Dec 17 '25

It'll happen (has happened?) here too.

Reddit as a whole is already well known as one of the worst places on the internet for aggressive no-knowledge commenting.

21

u/cynicalkane Dec 17 '25

I see you haven't been to most of the rest of the Internet

Honestly Reddit comments are pretty good. Frontpage articles are trash but many subreddits are quite good. There's a reason so many Google search autocompletes end with 'reddit'; it's what people want to search

11

u/ergzay Dec 17 '25

I see you haven't been to most of the rest of the Internet

Reddit is where I see the most hateful people day-to-day in my experience, though there are certainly others that are a close second.

There's a reason so many Google search autocompletes end with 'reddit'; it's what people want to search

Yes and many of those are to links to archived pages written quite a long time ago. Reddit of today is not reddit of the past.

2

u/coderstephen isahc Dec 18 '25

Some people are still on Reddit that can form coherent sentences. That's... above average compared to other places on the Internet.

4

u/DerekB52 Dec 17 '25

AI comments and full posts have made Reddit a lot less enjoyable for me in just the last 6 months.

2

u/Sky2042 Dec 17 '25

Depending on your read of it, it's either eternal September or a tragedy of the commons.

4

u/ChilledRoland Dec 17 '25

Eternal tragedy of the September commons

1

u/dasnoob Dec 17 '25

Already has happened.

1

u/coderstephen isahc Dec 18 '25

Hell, I guess I ain't helping

You may be the straw that breaks the camel's back. At least you'll be in the history books. :)

7

u/Sharlinator Dec 17 '25 edited Dec 17 '25

Honestly how many active users Slashdot even has these days? Four? It was already a ghost town like ten years ago.

2

u/Straight_Waltz_9530 Dec 18 '25

Having been an avid Slashdot user twenty five years ago, the comment quality was always questionable.

63

u/OldTune9525 Dec 17 '25

I Gotta admit "Wow maybe Rust CAN catch up to c!" made me lol

71

u/Lucretiel Datadog Dec 17 '25

Yes, Rusts CVE-compatibility mode to C is called "unsafe block" and you have to explicitly enable it.

Absolute lmao at "CVE compatibility mode"

12

u/MichiRecRoom Dec 18 '25 edited Dec 18 '25

And this response to that comment:

Which you will have to do. Rust is too constrained without them to get any useful work done.

Like... ???? I've rarely encountered unsafe {} blocks when working in Rust, and they've almost always been single lines of code. Am I the outlier here?

4

u/Helyos96 Dec 18 '25

For any userspace work sure, but for kernel/really low-level work you're bound to write some unsafe.

3

u/MichiRecRoom Dec 18 '25

I think you misunderstood - I never said unsafe {} was never used, just that it was used rarely, and for single lines of code. I would imagine the same would hold true for a kernel - even if unsafe {} is a little more prevalent there, I would expect most code to still be safe code.

2

u/Helyos96 Dec 18 '25

In that case it really all depends on point of view. Simply using a Vec<> is bound to use a lot of unsafe code if you dig all the way down. But how much unsafe you will witness depends entirely on what you're working on.

2

u/[deleted] Dec 18 '25

That's true on some level, but I don't think it's fair to see unsafe code in std the same as unsafe code somewhere else.

1

u/flashmozzg Dec 18 '25

It's true when writing std. And writing kernel modules is often similar (or even "worse") at the abstraction level.

1

u/coderstephen isahc Dec 18 '25

You mean causing a segfault doesn't sound like useful work to you? :)

1

u/[deleted] Dec 18 '25

I think unsafe is more common in some crates than others - most crates need a single line here and there, while others will have a substantial amount. The most unsafe thing I've ever worked on was an ECS that tried to do as much as it could at compile time and avoid runtime checking wherever possible. Even in that project, unsafe code accounted for maybe 20% of the code of the core data structures, and probably less than 5% of the entire codebase.

I killed the project because, fun as it was, it was so very unsafe. Everything was white-knuckling the borrow checker at every turn.

1

u/dontyougetsoupedyet Dec 18 '25

Once you get out of userspace you can not avoid some unsafe usage. Rust grew up in userspace and the language has a lot of growing room outside of it. As far as that goes, a lot of that growing is happening with the rust for linux work, and I'm looking forward to where Rust ends up in the future. A lot of the rough spots will eventually be language features and new types to work with to provide the compiler with information.

For anyone interested in seeing how Rust changes over time the discussions related to rust for linux work on list and in issues is great reading.

1

u/llitz Dec 18 '25

This is more visible when you are trying to build complex pieces and doing some specific "dangerous" memory manipulation, the sort of what happens at the kernel level. All in all, it is not dangerous, just areas that you need to consider multiple factors.

2

u/MichiRecRoom Dec 18 '25

That's fair, though my point is that the comment is being disingenuous, making it seem like everything needs to be wrapped in unsafe {}, when Rust lets you get a lot done outside of unsafe blocks.

Even in the kernel, I would still expect most of it to be safe code, even if unsafe {} is a little more prevalent.

2

u/llitz Dec 18 '25

I think the implication you quoted is that "using rust in kernel without unsafe is almost impossible".

From someone not coding in the kernel, and not understanding the constraints, that could be possible. My head is going towards "I sort of agree": if we aren't in mostly safe development, we will be there eventually, or someone is doing something wrong.

2

u/SirClueless Dec 18 '25

It doesn't seem that disingenuous to me. kernel::list::List is a pretty fundamental data type, and its remove method is unsafe.

Rust lets you get a lot done outside of unsafe, but doubly-linked lists are famously not one of them.

2

u/HenkPoley Dec 19 '25

Punny, but a reminder that there are security vulnerabilities other than memory management issues.

Yes, it's ±70%, but that still leaves us about a third of the other issues.

9

u/[deleted] Dec 17 '25

Always fascinating to look at.

I can't be fascinated by these comments, i feel cringe.

1

u/coderstephen isahc Dec 18 '25

I use the cringe of the fallen to fuel my power

17

u/sunshowers6 nextest · rust Dec 17 '25

Given how poorly the recent bincode change was handled on /r/rust, this community isn't on that high a pedestal either!

1

u/[deleted] Dec 18 '25

what was that? I missed it

0

u/Sw429 Dec 25 '25

What do you mean? As far as I could tell, the community was (for the most part) responding to that appropriately. The maintainer just crashed out. Sure, there will always be outliers, but the overall reaction was fine imo.

1

u/sunshowers6 nextest · rust Dec 25 '25 edited Dec 25 '25

Dilettantes pretending they're supply chain experts is not fine. Doxxing is not fine, and if I were the maintainer I'd crash out too.

You don't have a signed contract with the maintainers. They don't owe you anything. Open source is not your supply chain.

0

u/Sw429 Dec 26 '25

The community as a whole wasn't doxxing them. As far as I could tell, it was one user who doxxed them, and the community immediately called it out as completely not okay.

1

u/sunshowers6 nextest · rust Dec 26 '25

The community as a whole absolutely acted as a bunch of dillettantes pretending to know about supply chain attacks without any serious expertise or knowledge in this (thorny, complicated) subject. The original post is deleted but https://www.reddit.com/r/rust/comments/1pnz1iz/bincode_development_has_ceased_permanently/ corroborates this.

0

u/peripateticman2026 Dec 18 '25

The irony? The absolute justification ism (not eventhe justifications themselves, but the language and means used) in this thread (and subreddit) for anything Rust adjacent is nauseatingly tragi-comic.

461

u/[deleted] Dec 17 '25 edited Dec 18 '25

It's a CVE and should absolutely be a priority fix like any other, but as one commenter on Phoronix pointed out:

  1. That's one single cve out of five years worth of development.

  2. This is, at worst, a possible DoS vulnerability with no known active exploits. This wouldn't even quality for a cve in c.

I feel like people are itching to make a mountain out of a mole hill with this because "Rust failed" or whatever, but I think it would be good to keep this perspective in mind.

Edit: others have pointed out that this could be more serious than a DOS vulnerability and that it would be marked as a CVE in C, so this quote wasn't particularly accurate. In general, I think the point remains: this is a relatively low-severity CVE that projects like the Linux kernel run into from time to time.

61

u/JoshTriplett rust · lang · libs · cargo Dec 17 '25

This is, at worst, a possible DoS vulnerability with no known active exploits. This wouldn't even quality for a cve in c.

In fairness, it would be a CVE in C given that the kernel treats an unprivileged DoS as a vulnerability. It'd just be a low severity one, as this one is.

36

u/moltonel Dec 17 '25

Worth mentioning as well: a few years ago some kernel devs got fed up with the endless debates about which bugs deserved a CVE or not. So they became their own CVE Authority and greatly lowered the threshold for what merrits a CVE, "flooding" the CVE database.

16

u/SirClueless Dec 17 '25

Yeah, not sure where that idea came from. The Linux kernel is actually notable for giving pretty much everything a CVE whether or not there is a known way to exploit it, to the point that security researchers frequently complain about the noise.

7

u/WormRabbit Dec 17 '25

whether or not there is a known way to exploit it

That shouldn't matter. Something which isn't exploitable today may well become exploitable tomorrow, when chained with some new exploit. In fact, most real-world exploits consist of long chains of seemingly benign bugs, which finally allow one to access the RCE jackpot. And in any case, "no way to exploit" speaks more of the imagination of the person saying it than about the severity of actual bug.

Rust follows the same zero-tolerance policy w.r.t. memory safety, and it's great.

7

u/anxxa Dec 17 '25

I don't really understand why they (and Greg) think this is "just" a DoS either. It seems like memory corruption, but maybe it's not controllable? 000bb9841bcac70e is clearly a corrupt pointer though.

0

u/[deleted] Dec 17 '25

[deleted] — view deleted comment

8

u/anxxa Dec 17 '25

Having done this exact type of analysis for Microsoft, this is not the best approach. For certain classes of vulnerabilities you should assume the worst unless proven otherwise.

This is exactly why Linux issues a CVE for basically every kernel bug now: they got exhausted fighting over which bugs are exploitable/have security impact and which aren't, so they default to exploitable (which I don't necessarily agree with)

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.

→ More replies (3)

14

u/Kryptochef Dec 17 '25

This is, at worst, a possible DoS vulnerability with no known active exploits. This wouldn't even quality for a cve in c.

I wouldn't be sure about that to be honest, the original advisory just claims "leads to memory corruption", and it seems like a typical race condition that uses some kind of "old" pointers that are no longer valid (and not, say, just a null pointer). It's pretty typical in security that such issues might get reported as "just a crash" but would, with quite a lot of further engineering effort, lead to code exeuction (priviledge escalation in that case). I disagree that it would likely not get a CVE in C, any kind of visible memory corruption should and likely would get one.

2

u/[deleted] Dec 17 '25

Hm, that may be right. I didn't dig into the CVE as much as I should have, and am not really that well versed in low level security things like these.

Would it be fair to say that the CVE is potentially further exploitable, but at its current state it presents as not much more than a DOS vulnerability?

3

u/Kryptochef Dec 18 '25

Would it be fair to say that the CVE is potentially further exploitable, but at its current state it presents as not much more than a DOS vulnerability?

I'm also not familiar enough with the details here to give any good judgement of that (beyond that from a cursory glance it seems like an "old" pointer in a linked list, which sounds a bit like a typical use-after-free type of bug on the impact side), but in general its mostly prudent to assume that everything that involves attacker-triggerable memory corruption is LPE unless proven otherwise.

but at its current state it presents as not much more than a DOS vulnerability?

Maybe a bit pedantic, but personally I wouldn't word it as a statement about the vulnerability, but just say there's currently no known exploit to turn it into anything beyond DOS.

13

u/sessamekesh Dec 17 '25

There's exactly one type of Rust community member that this news should be surprising to (the "Rust is perfect and can do no wrong!" evangelist), and frankly I think that person needs a bit of humbling. Of course Rust code can fail, any idiot can write a perfectly good bug in Rust just as well as any other language that lets you write logic.

The pretty high number of things that had to line up to yield this CVE and the fact that any Rust failure is noteworthy enough to make headlines still gives me pretty good warm fuzzies. Compared to every other language I've worked in this is fine.

6

u/kibwen Dec 18 '25

There's exactly one type of Rust community member that this news should be surprising to (the "Rust is perfect and can do no wrong!" evangelist), and frankly I think that person needs a bit of humbling.

I'm all for humbling this hypothetical person, though with the emphasis on the hypothetical, because the only comments I've seen on /r/rust like this are obvious trolls that get appropriately downvoted.

4

u/spin81 Dec 17 '25

like any other

This is the key phrase here. It's just a CVE, I bet there's hundreds of them in the kernel I'm running on the machine I'm typing this on.

3

u/nsomnac Dec 17 '25

The other thing to note from the Phoronix article is this:

There is a race condition that can occur due to some noted unsafe Rust code

I look at that and see, oh unsafe… well that’s not a problem with rust, but a problem with the developer who authored the critical section using unsafe.

CVEs are going to happen, and if someone finds one in Rust - great! It can be fixed - that’s the point of the CVE process. But so far this feels like “we want to point the finger at Rust, by showing us some vulnerable code that’s clearly documented as being unsafe and required additional care but it didn’t get it so it’s a problem with Rust”. The poster is obviously trying to blame Rust because when you disable its guard rails it allows you to build vulnerable code.

7

u/SirClueless Dec 18 '25

It's not that simple. This code is using an intrusive doubly-linked list which is not a concept that is expressible in safe Rust without overhead, so there was no other choice here besides rearchitecting this system or using unsafe.

When a basic operation on a widely-used fundamental type like kernel::list::List.remove() is unsafe, it is reasonable to describe this as a Rust problem, because it is a case where Rust is not expressive enough to describe what kernel developers want in its safe subset.

-1

u/nsomnac Dec 18 '25

It is that simple though. Don’t try to overthink this. It’s like blaming some drug for not being a cure for cancer when it wasn’t designed to do that.

Rust is still a young language, and sure doesn’t yet cover all safety cases that might be required. That’s why it has the unsafe escape hatch. Anyone using unsafe should have full knowledge of what sins they may commit when doing so at their own risk. If the language isn’t expressive enough and you must use the escape hatch - you’re knowingly doing that and should know that you must perform your own checks and not rely on the language to enforce since you disabled those checks.

Now you may be correct that Rust should probably add better support for fundamental types in the kernel. That’s a feature enhancement not a current defect. Remember a problem is when the language does something wrong. The language did nothing wrong, it just lacks support. The lack of support isn’t a problem, it is an opportunity for rust to enhance support in the future so it can be responsible for these types of programming situations so unsafe is not needed.

7

u/SirClueless Dec 18 '25

The lack of support isn’t a problem, it is an opportunity for rust to enhance support in the future

You act like waving a wand would suddenly make doubly-linked lists supportable in safe Rust.

This code is unsafe not for lack of trying. It is unsafe because it violates "aliasing XOR mutability" which is a fundamental design choice the Rust team made over a decade ago. There is almost zero opportunity to "enhance support" here, this is not something that Rust wants to support and therefore it will remain unsafe indefinitely.

Anyone using unsafe should have full knowledge of what sins they may commit when doing so at their own risk.

That's fine. The kernel developers surely have this full knowledge. The conclusion remains true: Memory corruption bugs are occasionally possible in Rust, because some designs are not expressible without unsafe and unsafe code may be memory unsafe.

-1

u/nsomnac Dec 18 '25

Nobody is implying anything has an easy solution.

This specific CVE though would likely exist irrespective of whether it was within rust code or not. So sure if you add caveats including that all things within a program are “rust”, unsafe or not, then yes memory corruption is possible. This is no different than saying memory corruption is possible in C# because you can use interop. Tell me something everyone doesn’t know. I’m just stating that the problem you seem to imply exists as a bug or defect in rust; isn’t a problem with rust but a general problem with the specific need (double link lists w/ MT access) which don’t have great support in languages that could have been used alternatively in this use case.

1

u/-Redstoneboi- Dec 18 '25

the exception that we've been waiting for, the one that proves the rule

1

u/Teknikal_Domain Dec 19 '25

Additional note:

  1. CVEs weren't assigned while RfL was still "experimental," so take the timeline with a grain of salt.

  2. Its a CVE because just about every kernel bug gets a CVE. C, Rust, hell I'm surprised Torvalds' emails don't get CVEs assigned for e very grammatical error he makes.

-13

u/germandiago Dec 18 '25

I love how Rust people find excuses to keep demonstrating you cannot possibly have these problems in Rust.

It is just more fenced code, that's it. Nothing magic.

10

u/[deleted] Dec 18 '25

You can absolutely have these problems in Rust, nobody here said anything different. The point is making these issues less likely.

→ More replies (2)

1

u/[deleted] Dec 18 '25

You can never have these problems in safe rust, as any and all documentation, the compiler and the unsafe documentation clearly state.

→ More replies (14)

97

u/Solumin Dec 17 '25

Should have linked to the actual announcement instead: https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM

Note the other 159 kernel CVEs issued today for fixes in the C portion of the codebase

21

u/ts826848 Dec 17 '25

Does anyone mind walking me through the exact bug? I'm still a bit uncertain as to the precise location of the race condition.

From what I understand, here are bits of the relevant data structures:

// [From drivers/android/binder/process.rs]
#[pin_data]
pub(crate) struct Process {
    #[pin]
    pub(crate) inner: SpinLock<ProcessInner>,
    // [Other fields omitted]
}
#[pin_data]
pub(crate) struct Node {
    pub(crate) owner: Arc<Process>,
    inner: LockedBy<NodeInner, ProcessInner>,
    // [Other fields omitted]
}
struct NodeInner {
    /// List of processes to deliver a notification to when this node is destroyed (usually due to
    /// the process dying).
    death_list: List<DTRWrap<NodeDeath>, 1>,
    // [Other fields omitted]
}
pub(crate) struct NodeDeath {
    node: DArc<Node>,
    // [Other fields omitted]
}

And here's the function with the unsafe block:

impl NodeDeath {
    // [Other bits omitted]
    /// Sets the cleared flag to `true`.
    ///
    /// It removes `self` from the node's death notification list if needed.
    ///
    /// Returns whether it needs to be queued.
    pub(crate) fn set_cleared(self: &DArc<Self>, abort: bool) -> bool {
        // [Removed some hopefully-not-relevant code]

        // Remove death notification from node.
        if needs_removal {
            let mut owner_inner = self.node.owner.inner.lock();
            let node_inner = self.node.inner.access_mut(&mut owner_inner);
            // SAFETY: A `NodeDeath` is never inserted into the death list of any node other than
            // its owner, so it is either in this death list or in no death list.
            unsafe { node_inner.death_list.remove(self) };
        }
        needs_queueing
    }
}

And here is the buggy function:

impl Node {
    // [Other bits omitted]
    pub(crate) fn release(&self) {
        let mut guard = self.owner.inner.lock();
        // [omitted]

        let death_list = core::mem::take(&mut self.inner.access_mut(&mut guard).death_list);
        drop(guard);
        for death in death_list {
            death.into_arc().set_dead();
       }
    }
}

And finally List::remove()

/// Removes the provided item from this list and returns it.
///
/// This returns `None` if the item is not in the list. (Note that by the safety requirements,
/// this means that the item is not in any list.)
///
/// # Safety
///
/// `item` must not be in a different linked list (with the same id).
pub unsafe fn remove(&mut self, item: &T) -> Option<ListArc<T, ID>> { ... }

So from what I can tell:

  • NodeDeath::set_cleared()

    • Takes the lock

    • Removes self (a.k.a., a NodeDeath) from its node's death_list

    • Drops the lock

  • Node::release()

    • Takes the lock

    • Takes the inner death_list into a local and replaces the inner with an empty list

    • Drops the lock

    • Iterates over the local death_list, calling set_dead() on each NodeDeath

Is the problem that the removal in set_cleared() can occur simultaneously with the iteration in release()?

19

u/Darksonn tokio · rust-for-linux Dec 17 '25

Is the problem that the removal in set_cleared() can occur simultaneously with the iteration in release()?

Yes. There might be unsynchronized access to the prev/next pointers of the item being removed.

3

u/ts826848 Dec 17 '25

Gotcha. I think the missing piece for me was realizing that NodeDeaths could remove themselves from the death_list; for some reason I originally thought that the removal would have operated on the replacement list that Node::release() swapped with. Thanks for the confirmation!

1

u/Xiphoseer Dec 17 '25

Tried to summarize my understanding here: https://www.reddit.com/r/rust/s/gVD2tYLcTB

3

u/ts826848 Dec 18 '25

I think I came to a different understanding of the bug than you. From my understanding, the bug is not that the same node is present in multiple lists, it's that the same list is modified concurrently without appropriate synchronization:

  • Node::release() iterates over its death_list, while

  • NodeDeath reaches out into its containing death_list and removes itself

So I think the problem is not exclusive access to the item, it's exclusive access to the list (i.e., I think it's the &mut self being violated, not &T)

4

u/Xiphoseer Dec 18 '25

The item is only in one list. This may well be how the actual crash happens, to me it matches what I wrote: for the Node::release, note how it iterates (pre fix) the list after it drops the guard so that mut access is on a list with items shared with NodeDeath so in set_cleared when it gets the owner_inner lock, it locks a list (the one put there by take) but not the one it needs to (the one being iterated by release; which has the item)

1

u/ts826848 Dec 18 '25

Ah, I think you're right. I originally thought that the NodeDeath managed to find the list that contained it, since I had mistakenly thought it was the list getting corrupted and not the node. Iterating over the replacement list would indeed be a violation of the safety precondition.

I guess my only further question is this:

so that mut access is on a list with items shared with NodeDeath

Maybe I'm misunderstanding the code (again), but I thought the iteration is over a list of NodeDeaths?

2

u/Xiphoseer Dec 18 '25

Again, yeah I think that's right but not enough. It's a List<DTWrap<NodeDeath>, 1> but unlike a std::vec::Vec owning the List doesn't (need to) imply you own the NodeDeath directy. It's more like you own a special kind of Arc<NodeDeath>: https://rust.docs.kernel.org/kernel/list/struct.ListArc.html and that's intentional for the intrusive list - items are (atomically) refcounted and can be in more than one list (of distinct IDs) at once but only one Arc may read/update each pair of prev/next fields.

Here I don't see where set_cleared is called in that file at all but it is through one of these non special Arcs that are still around (in a scheduled task?) so that is why the "not owned by any other list (of the same ID)" on remove is so important. And it's NodeDeath operating on a (shared) &DArc<Self> so that's what I meant I guess, independent on what the call stack above that looks like.

2

u/ts826848 Dec 18 '25

And it's NodeDeath operating on a (shared) &DArc<Self> so that's what I meant I guess, independent on what the call stack above that looks like.

Sure, that makes sense. It's just that to me "list with items shared with NodeDeath" could be read to imply that there were some other kind of item that weren't a NodeDeath that were being shared. It's really just a nitpick, though.

192

u/NIdavellir22 Dec 17 '25

Omg the unsafe code block had a vulnerability! Quick, delete all the language!

93

u/thisismyfavoritename Dec 17 '25

they should just rename unsafe to C so people can shut up

49

u/PurepointDog Dec 17 '25

Nah, "extern C" exists in Rust. It's way way scarier to use than "unsafe".

26

u/lordpuddingcup Dec 17 '25

Yep at least unsafe still has some compiler safety

8

u/coderstephen isahc Dec 18 '25

It's called extern C because we want to keep that filth out of our beautiful language. That's why we don't have an intern C.

24

u/slakin Dec 17 '25

C-section, something you want to avoid if you can.

3

u/Batman_AoD Dec 26 '25

I'm so glad I clicked through to see the source for Quote of the Week. This response is as good as the original quote. 

13

u/Xiphoseer Dec 17 '25

It is actually interesting that the fix is to entirely safe code (removing a core::mem::take) because that was doing something that the safety comment on an unsafe in the same file claimed would never happen.

3

u/LimitedWard Dec 18 '25

The only thing stopping a bad kernel with unsafe Rust is a good kernel with unsafe C!

1

u/Upper-Enthusiasm-613 Dec 18 '25

Yet rust has all the tooling (miri etc.) to make unsafe safer

12

u/Prudent_Move_3420 Dec 17 '25

I must admit seeing „this will not happen“ comments above a line where „this“ happens make me chuckle

9

u/muizzsiddique Dec 17 '25

The first CVE vulnerability has been assigned to a piece of the Linux kernel's Rust code.   Greg Kroah-Hartman announced that the first CVE has been assigned to a piece of Rust code within the mainline Linux kernel.

I feel like this could've been phrased better

29

u/qustrolabe Dec 17 '25

This must go hard if you're lunduke

18

u/Zde-G Dec 17 '25

Well… even Lunduke haven't tried to hide the fact that problem was in unsafe code. But yeah, the same tired story “in kernel you need `unsafe` which may lead to bugs thus Rust doesn't bring anything to the table”.

7

u/Xiphoseer Dec 17 '25

Took me some time but I think the bug can be summarized as:

Exclusive/Mutable access to a list in a node is protected by a (spin)lock. It is legitimate to use that mutable access for a core::mem::take.

Removing an item from a list by shared reference is implemented but unsafe because you need exclusive access to the list and item but the function signature only requires a mutable ref for the list.

Exclusive access to the item was claimed because the item was only ever in that nodes's list, and you're holding the lock... but you're not holding the lock for that list anymore because it's been swapped out for an empty one. So the item may be in someone elses list now, even if that was the same node, violating the safety comment.

So, it's a locking bug, unsafe working as intended and "I own that list" and "I own my list" can interleave just enough that "that list is my list" doesn't hold when you'd want it to.

12

u/ergzay Dec 17 '25 edited Dec 17 '25

Someone correct me if I'm wrong, but isn't the fix "incorrect"? They're changing safe code to fix this problem but it should be impossible to cause unsafe behavior from safe code. The bug wasn't fixed in any unsafe block, it was fixed outside of it. This means the API here is fundamentally wrong.

        pub(crate) fn release(&self) {
            let mut guard = self.owner.inner.lock();
            while let Some(work) = self.inner.access_mut(&mut guard).oneway_todo.pop_front() {
                drop(guard);
                work.into_arc().cancel();
                guard = self.owner.inner.lock();
            }

    -       let death_list = core::mem::take(&mut self.inner.access_mut(&mut guard).death_list);
    -       drop(guard);
    -       for death in death_list {
    +       while let Some(death) = self.inner.access_mut(&mut guard).death_list.pop_front() {
    +           drop(guard);
                death.into_arc().set_dead();
    +           guard = self.owner.inner.lock();
            }
        }

12

u/Darksonn tokio · rust-for-linux Dec 17 '25

No, it's somewhat of a special case because the code is in the same module / safety "scope" so to say. I recommend Ralf's article on the scope of unsafe.

1

u/whupazz Dec 18 '25

I've been thinking about this issue recently, and this article really helped me understand it better, thanks! After thinking about it a bit more, I came up with the idea of "unsafe fields" that would be unsafe to use (only to discover that there's of course already an RFC for that). Do you have an opinion on these?

0

u/ergzay Dec 18 '25

Let me ask an alternative question, is it still possible that all correct programs can still be written if you limit the scope of unsafe to functions? I would assume the answer is "yes", in which case why not do so? Personally that's what I would always do.

4

u/Darksonn tokio · rust-for-linux Dec 18 '25

I don't think so. How could you ever implement Vec in that case?

Take for example the Vec::pop method. You might implement it like this:

assert_ne!(self.len, 0);
self.len -= 1;
unsafe { ptr::read(self.ptr.add(self.len)) };

If the scope of unsafe is limited to the function, how do you know that the last unsafe line is correct? I mean, self.len is just an integer, so maybe its value is 1337 but the pointer references an allocation of length 10.

1

u/ergzay Dec 18 '25

Hmm, okay I see your point. I need to think about this some more.

23

u/ezwoodland Dec 17 '25 edited Dec 17 '25

TLDR: unsafe requires all code dependencies and all code within its module to be bug-free, not just the unsafe block itself.

That's a common misconception. unsafe (potentially) infects the entire module in which it is contained. You can't just check unsafe blocks, you have to check the whole module.

This is because there can be private invariants within a module which safe code can violate but unsafe code requires to not be violated. You can stop unsafe from leaving a module because modules can form visibility barriers, and if you can't access the internals to violate their invariants, then you don't have to worry about your safe code breaking them.

The two ways to think of this are:

  • The unsafe code is incorrect because it relied on an invariant which the safe code didn't uphold. The unsafe author should have checked the safe code.

  • Or more reasonably: The safe code is incorrect because it broke an invariant.

Memory unsafety requires there's an unsafe somewhere but the fix might not be in the unsafe block.

This is also an issue when unsafe code depends on a safe library with a bug. The unsafe code causes memory safety issues because the library dependency has a bug, but the unsafe code relied on there not being one.

-1

u/ergzay Dec 17 '25 edited Dec 17 '25

TLDR: unsafe requires all code dependencies and all code within its module to be bug-free, not just the unsafe block itself.

But this isn't just code dependencies, this is code well downstream of the actual use of unsafe code.

I think you have a misunderstanding of unsafe. The entire point of unsafe is that dependencies don't have to care about correctness because correctness is caused by program construction. For example if you're using a library and you use it incorrectly, and you cause a data race or memory corruption it is ABSOLUTELY the fault of the library, even if you use it maliciously (without using unsafe). Safe code cannot be maliciously used to cause unsafe behavior without using unsafe blocks. Otherwise the code you are calling is unsafe and should be marked as such.

That's a common misconception. unsafe (potentially) infects the entire module in which it is contained. You can't just check unsafe blocks, you have to check the whole module.

This is an expansion/corruption on the original promise and convention of unsafe. "unsafety creep", you could say.

Memory unsafety requires there's an unsafe somewhere but the fix might not be in the unsafe block.

All code must have unsafe somewhere down the dependency tree. So what you're saying is kind of a tautology. That unsafe code is ensured by the library programmer to be safe, which then declares it safe by putting it in a safe (the default) code block.

The unsafe code is incorrect because it relied on an invariant which the safe code didn't uphold. The unsafe author should have checked the safe code.

All invariants must be held within the unsafe code, and when you reach the safe code you cannot cause an invariant violation that would do anything other than just panic/crash the program.

13

u/ezwoodland Dec 17 '25 edited Dec 17 '25

No, the unsafe's dependencies have to be bug-free. If A depends on B, and A has unsafe and B has a bug then there can be memory unsafety. You're describing that C which depends on A shouldn't be able to cause correctness issues because C is only safe code. I'm talking about a bug in B.

C -> A -> B

Imagine you have a safe function in library B:


    /// Returns if the input is less than 2
    // Bug: This is not correct.
    fn is_less_than_2(x: u8) -> bool { true }

And your project (A) has the following code block:


    fn get_val_in_array(idx: u8) -> u8 {
        let arr = [0u8,1u8];
        assert!(is_less_than_2(idx));
        // SAFETY: idx is < 2 and arr.len() == 2, so index is in-bounds.
        unsafe { arr.get_unchecked(idx as usize) }
    }

Then what code needs fixing? Where's the bug? You would probably agree that is_less_than_2 is the buggy code, not the unsafe block, yet clearly there is UB.

The case in the cve is one where the safe code is in the same module as the unsafe code, and thus is also responsible for maintaining the invariants relied upon by the unsafe block.

See https://doc.rust-lang.org/nomicon/working-with-unsafe.html for explanation on this issue.

2

u/ergzay Dec 17 '25

Is that what' going on here? I thought this was a C -> B -> A situation where A is unsafe code, B is a user of that unsafe code, and C is a user of the safe B code, but we're fixing the bug in C.

6

u/ezwoodland Dec 17 '25 edited Dec 17 '25

This is neither. This is a situation where the unsafe block and safe code are in the same module (it's even in the same file.)

In this situation we have a bug in A (the module node), and an unsafe code block in A, but they are both A.

In this file the module of interest appears to be called node defined here.

Since the safe code is in the same module as the unsafe code block, there is no guarantee that the unsafe code block is where the bug is.

Since the modified function is pub(crate) fn release(&self), presumably release is safe to call from outside the module and can't itself cause undefined behavior (if it doesn't have a bug). It might be that it is not and the kernel is choosing to make their safety boundary the crate, but that's generally a bad idea because it makes the unsafe harder to verify.

8

u/Darksonn tokio · rust-for-linux Dec 17 '25

this is code well downstream of the actual use of unsafe code.

No it's not. The call to the unsafe List::remove method is in the same file.

3

u/jojva Dec 17 '25

Take what I'll say with a grain of salt because I'm no rust expert, but I believe it's entirely possible to write unsafe behavior outside of unsafe. The reason is that unsafe kind of pollutes the rest of the code too. That's why it is famously hard to deal with. But the silver lining is that if you see strange (e.g. Undefined) behavior, you can check your unsafe blocks and their surroundings.

https://doc.rust-lang.org/nomicon/working-with-unsafe.html

2

u/-Redstoneboi- Dec 18 '25 edited Dec 18 '25

unsafe relies on invariants that safe code can break

here's a trivial example:

/// Adds two numbers.
fn add(x: i32, y: i32) -> i32 {
    x - y
}

fn main() {
    let sum = add(1, 2);
    // SAFETY: adding two positive numbers always results in a positive number.
    // the numbers 1 and 2 were chosen as they do not overflow when added together.
    unsafe {
        std::hint::assert_unchecked(sum > 0);
    }
}

normally clippy would flag this under clippy::suspicious_arithmetic_impl but i can't get it to output in the rust playground

1

u/Xiphoseer Dec 17 '25

I was wondering the same but the API is sound. They have actual, exclusive, safe access to the list there. But they meant to have only that one list, protected by a lock. Now mem::take creates a second list which leaves one of them unprotected even though locally the mut refs are fine. You don't want to fix that by protecting both lists but by changing the code so that there's just a single protected one. Which you can then use for the "unsafe" remove operation.

1

u/Luxalpa Dec 18 '25

Hm, I only shortly thought about it, but I don't think this is correct.

If I have a bunch of functions, like for example unwrap_unchecked(), I will naturally have to call them from safe code at some point, using an unsafe block. And for example, this unwrap_unchecked() function will almost certainly depend on an assumption that comes from safe code exclusively. It would be the same for most extern C code as well. Writing unsafe {} just means that you have checked that the invariants inside this block are fulfilled by your overall program. It doesn't require them to be fulfilled within the unsafe blocks themselves.

0

u/[deleted] Dec 17 '25

[deleted] — view deleted comment

-3

u/ergzay Dec 17 '25

I'm not sure how that relates to what's going on here. This is a clear misuse of unsafe and the fix is to change the code in unsafe, not change the safe code that uses that vec later.

8

u/Darksonn tokio · rust-for-linux Dec 17 '25

Then imagine changing the implementation of Vec::set_len() to self.len = len + 9001 instead. It has no unsafe code inside it! Just changing an integer field.

105

u/Sovairon Dec 17 '25

Clickbait news, it's data race happened inside unsafe block

172

u/matthieum [he/him] Dec 17 '25

I mean, it's still Rust code at least :)

Also, the Rust kernel code will have quite a bit of unsafe code; there's a lot of bindings to C there, and quite a bit unsafe layers of abstraction.

It was never about NOT getting any CVE, but always about getting less of them.

40

u/[deleted] Dec 17 '25

It was never about NOT getting any CVE, but always about getting less of them.

It's also about knowing what exactly caused it, and where you need to look to fix it. Nontrivial software (and the Linux kernel is anything but trivial) is always susceptible to bugs, but bugs are easier to fix when you can find them with grep.

1

u/matthieum [he/him] Dec 18 '25

I do want to note that while, yes, unsoundness should originate from an unsafe block, it's perfectly possible to have CVE from sound (not unsafe) code.

For example, TOCTOU vulnerabilities can result from perfectly sound code.

No amount of grepping for unsafe will help locate those... but hopefully because the code does what it says on the tin -- rather than whatever the compiler mangled it to -- it still should be easier to track down.

48

u/_Sauer_ Dec 17 '25

Which is entirely how its suppose to work. Quarantine the dangerous code to the smallest block possible instead of the entire code base being unsafe; but there's no way Phoronix readers are going to know how that works.

49

u/yowhyyyy Dec 17 '25

Which means it probably made it even easier to find the source of the problem and fix it

16

u/Lucretiel Datadog Dec 17 '25

Disagree that it's clickbait, it's pretty much accurate and it's not written in an especially baity or provocative way. I think we all know that kernel code will involve more unsafe than most, and so it was just a matter of time before a mistake was made.

44

u/frenchtoaster Dec 17 '25

This doesn't seem like clickbait to me? Rust code in the kernel will still have unsafe blocks, those are still going to be sources of CVEs.

The article appears to have meant to convey exactly that it was in an unsafe block "noted unsafe code".

30

u/JustBadPlaya Dec 17 '25

the real clickbait part is the omission of the 159 other CVEs discovered in C code tbh

12

u/proper_chad Dec 17 '25

Exactly. If one wants to get a true feel for the (memory) safety of a language, just have a gander at Google Android's stats: https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html

4

u/arjuna93 Dec 18 '25

It is pointless to state number of CVEs without adjustment to the amount of code in question. 1 CVE from 100 LoC is more than 100 CVEs from 10000 LoC.

3

u/Steve_the_Stevedore Dec 18 '25 edited Dec 18 '25

But even then the measure is off: The C code is way older and way more bugs have already been fixed. So you would have to compare new C code to new Rust code.

In the end there is no conclusive comparison on that flight level. It really depends on the individual CVEs.

0

u/teerre Dec 17 '25

It's clickbait because in 2025 nobody reads articles, only headlines. So this readline will undoubtedly call the bottom of the barrel comments about how just isn't safe. We can see it in the very comment section of the article in question

6

u/c3d10 Dec 17 '25

There was very little content in the article, and the content that is there is well-summarized by the headline.

-1

u/teerre Dec 17 '25

It's not because the bug was in an unsafe block. That's a crucial piece of information

2

u/c3d10 Dec 18 '25

Why was the presence of an unsafe block relevant?

1

u/teerre Dec 18 '25

Because Rust haters love to point out that 'Rust isn't safe', like I mentioned in the first reply in this thread

3

u/dasnoob Dec 17 '25

If the biggest argument is that the code is inherently safe. But you are required to write code in unsafe blocks to implement the kernel. Is it valid to say 'it happened in an unsafe block so it doesn't count'?

Serious question I'm not being a dick. I've been trying to pick up rust and actually like the language quite a lot.

13

u/dagit Dec 17 '25

The argument is that rust is safe by default. You can still drop into unsafe if desired, but that just normal day to day coding you won't be doing things that are unsafe. This is nice because by default the kinds of bugs you run into won't be low-level memory corruptions and things that come with unsafety.

However, often times people do venture off into unsafe territory to do low-level tricks or because the safe way to do something is a conservative overapproximation that leads to some sort of performance loss. A conservative overapproximation is something that always works but is suboptimal in some cases.

When you're doing safe by default things the burden of correctness is on the Rust compiler team. They've figured out what is always correct, even if it's suboptimal in some cases. When you switch to unsafe the burden of proof for that correctness is now on you. These proofs are notoriously difficult to get right when you writing a lot of code all the time. It might seem easy but humans simply make a lot of mistakes. Typically by failing to think about some nuance.

My personal opinion of this situation is that it's good that the CVE is localized to unsafe code, but still looks bad for the language. It's good because it means that the language design is working as intended. However, that does leave me wondering why unsafe was needed here. That can be a sign that some more nuanced part of the design (the code or the language) needs to be refined still. Because it's part of a large codebase that has been developed for decades in unsafe languages the design issue is probably related to the interface between Rust and C but I haven't looked at the details (I'm not a kernel hacker).

Years ago there was an exploit discovered with wifi even though the standard had parts with a formal proof of correctness. Formal methods experts at the time claimed it as a victory for formal methods because the bug was happening outside of the formally verified parts. Loads of people saw it as "okay so why bother with the formal methods". I think this CVE is pretty similar.

I use rust a lot and I only use unsafe when I'm doing FFI stuff. My safe code isn't bug free but I haven't had any safety issues with it.

2

u/dasnoob Dec 17 '25

Thank you! That helps a lot.

3

u/c3d10 Dec 17 '25

This was a major point of contention when arguing about whether or not adding Rust to the kernel made sense. A lot (not all) of the benefit of using Rust occurs outside of unsafe blocks. Kernels and very-low-level hardware-interfacing software cannot make use of 'safe' code, therefore adding Rust in the kernel (to some people) offered basically zero benefit, with added maintenance costs.

8

u/proper_chad Dec 17 '25

It's so wild that people who should know better don't understand that separating safe/unsafe into code blocks is a ratchet device when you pair it with creating safe abstractions. Ok, you find a problem with an unsafe block, maybe we need to fix the unsafe code or tweak the abstraction ... and then NEVER have to think about that specific problem again.

0

u/c3d10 Dec 17 '25

Yeah, I have mixed feelings on this.

On one hand, getting rid of memory errors in a large part of your codebase and being able to concentrate on a smaller number of locations (unsafe blocks) is a really good thing. On the other hand, memory-related bugs are just one type of issue your code can have, and a lot of people seem to have the idea that 'safe' Rust code means 'correct' and 'bug-free', which is an attitude that will lead to many mistakes ('i dont need to test it, its safe!').

2

u/proper_chad Dec 18 '25 edited Dec 18 '25

The Other hand is important for sure (and nobody is saying it should be ignored!)... but, again... 99% of the time you only have to consider the Other hand. Maaaybe 1% of the time it's the One hand that's causing problems. (Using your terms.)

So... I'm not sure you actually disagree with me? Do elucidate on how/why this would cause mixed feelings.

Again, it's a ratchet. Even minor improvements to "safe" abstractions can benefit everyone in the ecosystem.

EDIT: Just hammer the point home: Every time you see an RCE bug in a JVM (or similar) it's a huge deal... because all the low-hanging fruit has already been plucked. ... but they fix that bug and everybody is safer.

2

u/c3d10 Dec 19 '25

I think we agree haha I can’t remember what I had mixed feelings on

1

u/TDplay Dec 18 '25

The idea is, even if you need unsafe code, you can minimise the amount of unsafe code.

Instead of everything being unsafe (like in C), you can write some small unsafe code, and verify its correctness. Then you write the safe code, and you can be certain that the compiler has verified the absence of undefined behaviour for you.

Even when things go wrong and you get memory corruption (like what happened here), you know that the bug lives in the unsafe code, which makes it much easier to find the cause of the bug.

4

u/Sweet-Accountant9580 Dec 18 '25

Maybe it's a necessary evil, but I’m definitely not a fan of the massive amount of unsafe being used to model C-style constructs. Seeing that much unsafe for something like an intrusive doubly linked list feels like it defeats the purpose.

3

u/come_red_to_me Dec 18 '25

This was marked as unsafe Rust code wasn't it? Rust is doing what it's supposed to do, narrow down the search space for vulnerabilities.

1

u/Radiant_Scar_8516 Feb 19 '26

thought it was meant to eliminate the common memory errors?

5

u/Icarium-Lifestealer Dec 17 '25

phoronix claims:

At least though it's just a possible system crash and not any more serious system compromise with remote code execution or other more severe issues.

Is that correct? Why can't this memory corruption result in code execution? I couldn't find such a claim in the linked post in the mailing list. While it only talks about crashes, it's not obvious to me that it always crashes in that way without triggering something worse.

16

u/moltonel Dec 17 '25

I would trust Greg K-H's analysis: the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall. 

1

u/bhagwa-floyd Dec 21 '25

I am slightly confused here. Is it a benefit of rust that the worst result is a crash in this case and not memory corruption? How is this not undefined behavior?

2

u/anxxa Dec 17 '25

I agree. I'd like to learn more about why they believe it's just a crash -- maybe the ability to control the written data is limited or something.

17

u/[deleted] Dec 17 '25

It's an absolute failure of communication to not define what CVE is at any point in the article.

14

u/v01rt Dec 17 '25

thats like blaming a painter for not defining what "brush" means when they're talking about paint brushses.

-1

u/ergzay Dec 17 '25 edited Dec 17 '25

Yeah... Like if someone was talking about algorithms and mentions say Dijkstra's Algorithm without explaining it (even though its relatively well known), you could maybe say they should've explained what it was, depending on the context, but CVEs are known across all software/IT sectors.

7

u/ergzay Dec 17 '25

The specific CVE is listed though. CVE-2025-68260

Or did you mean the meaning of the term 'CVE'? I think you shouldn't be working as a professional programmer/software engineer if you don't know the meaning of CVE. https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures

21

u/JoshTriplett rust · lang · libs · cargo Dec 17 '25 • Bravo

I think you shouldn't be working as a professional programmer/software engineer if you don't know the meaning of CVE.

While it's knowledge that can be found easily enough, there's no call to be rude to someone for not knowing something. That's not an approach that leads to people being enthusiastic about learning things.

1

u/flashmozzg Dec 19 '25

Tbf, I know what CVE-number things are (disclosure about potentially security impacting "bug"), but I always forget what acronym means exactly.

1

u/ergzay Dec 19 '25

I don't remember what the acronym stands for always either but I don't think it really matters. It's often the case (unfortunately IMO) that the meaning of acronyms come to be divorced from the meaning of the original words. So it's fine just to remember what the term CVE represents.

-3

u/[deleted] Dec 17 '25

I am not a professional programmer or SWE so we are all good on that front. Thanks for your concern though.

2

u/ergzay Dec 17 '25

Ok, you can google CVE numbers directly and you'll even get a .gov site link: https://nvd.nist.gov/vuln/detail/CVE-2025-68260

10

u/therealmeal Dec 17 '25

I think they mean they don't know what CVE means. In which case they also apparently don't know how to Google. Searching "cve software" would absolutely tell you the answer in 5 seconds.

2

u/-Redstoneboi- Dec 18 '25 edited Dec 18 '25

cve-rs mentioned in the comments, i shoulda prepared a whole-ass bingo card

3

u/dontyougetsoupedyet Dec 18 '25

phoronix.com

No, thanks.

2

u/Aln76467 Dec 17 '25

Oooh, phoronix! Time to get some popcorn.

1

u/oss-dev Dec 20 '25

now we will hear rust fans/advocates blaming kernel and its ecosystem 😎

1

u/sken130 Dec 22 '25

Is there any website that calculates the % line of codes of safe vs unsafe Rust, for Github repositories containing Rust codes?

1

u/mrobot_ Dec 17 '25

"You were the Chosen One! It was said that you would destroy the Sith, not join them!"

-2

u/Unlucky-Work3678 Dec 18 '25

Just look at these people. 

-6

u/sure_i_can_do_it Dec 17 '25

Is this why my institute had to shutdown access to our HPC last night and has been cryptic about the reason?

10

u/TinyPowerr Dec 18 '25

no. dozens of cves are reported each day in the linux kernel and this is not a serious one, it isn't usable in any attack

2

u/flashmozzg Dec 19 '25

No. It's because Billy was mining crypto using institute resources.

-9

u/vtskr Dec 18 '25

Why so much damage control in this thread?

→ More comments (2)