8 ms·

Linux Kernel Rust Code Sees Its First CVE Vulnerability

129 points by weinzierl 10mo ago

kahlonel 10mo ago
Now we have vulnerabilities in two different flavors.
greatgib 10mo ago
"That code can lead to memory corruption of the previous/next pointers and in turn cause a crash." Oh no, what happened to Rust will save us from retarded legacy languages prone to memory corruption?
- gfna 10mo ago
  Well the article did mention it was in an undafe block
  - greatgib 10mo ago
    1) unsafe block still of "rust" code that rewritten in "rust" to be safe compared to previous C code. 2) Maybe there is no other way than use "unsafe" block sometimes in "rust", so is Rust a lie?
    - AndrewDucker 10mo ago
      Rust constrains the code that can do unsafe things to small blocks, greatly reducing the area in which they can happen. Unlike C, where the whole of the code is unsafe.
    - gitaarik 10mo ago
      I imagine for some very low level kernel stuff, you might want to turn off Rust's safety features because they get in the way, make things less efficient or something. But then when you do you should really know what you're doing. The fact that this bug is because of "unsafe" Rust usage actually affirms the language's safety when using "safe" code. Although with "memory safe" code you can of course still fuck up lots of other things.
- deleted 10mo ago
  [deleted]
- techbrovanguard 10mo ago
  If you do something stupid in a block marked "unsafe", it's probably on you, my guy.
pa7ch 10mo ago
Honestly seems like zig is shaping up to be a better fit for kernel. Regardless the language that attracts skilled kernel devs will matter more then lang.
- postepowanieadm 10mo ago
  It's true only for unsafe rust.
- ameixaseca 10mo ago
  It is not - and given its stance on memory safety, it will hardly ever be.
- dralley 10mo ago
  Rust has been stable for 10 years. Zig is still not stable.
HumanOstrich 10mo ago
They're still 90% of the way to their goal. And there's only 90% left to go.
tekacs 10mo ago
To pre-empt the folks who'll come in here and laugh about how Rust should be preventing memory corruption... I'll just directly quote from the mailing list: Rust Binder contains the following unsafe operation: // 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) }; This operation is unsafe because when touching the prev/next pointers of a list element, we have to ensure that no other thread is also touching them in parallel. If the node is present in the list that `remove` is called on, then that is fine because we have exclusive access to that list. If the node is not in any list, then it's also ok. But if it's present in a different list that may be accessed in parallel, then that may be a data race on the prev/next pointers. And unfortunately that is exactly what is happening here. In Node::release, we: 1. Take the lock. 2. Move all items to a local list on the stack. 3. Drop the lock. 4. Iterate the local list on the stack. Combined with threads using the unsafe remove method on the original list, this leads to memory corruption of the prev/next pointers. This leads to crashes like this one:
- samdoesnothing 10mo ago
  If rust is so inflexible that it requires the use of unsafe to solve problems, that's still rust's fault. You have to consider both safe rust behaviour as well as necessary unsafe code.
  - woodruffw 10mo ago
    This is sort of the exact opposite of reality: the point of safe Rust is that it's safe so long as Rust's invariants are preserved, which all other safe Rust preserves by construction. So you only need to audit unsafe Rust code to ensure the safety of a Rust codebase. (The nuance being that sometimes there's a lot of unsafe Rust, because some domains - like kernel programming - necessitate it. But this is still a better state of affairs than having no code be correct by construction, which is the reality with C.)
    - gkbrk 10mo ago
secondcoming 10mo ago
[flagged]
drob518 10mo ago
Anybody who thought the simple action of rewriting things in Rust would eliminate all bugs was hopelessly naive. Particularly since Rust allows unsafe operations. That doesn’t mean Rust provides no value over C, just that the value is short of total elimination of bugs. Which was never advertised as the value to begin with.
- zamalek 10mo ago
  > Anybody who thought the simple action of rewriting things in Rust would eliminate all bugs was hopelessly naive All bugs is typically a strawman typically only used by detractors. The correct claim is: safe Rust eliminates certain classes of bugs. I'd wager the design of std eliminates more (e.g. the different string types), but that doesn't really apply to the kernel.
  - samdoesnothing 10mo ago
    > All bugs is typically a strawman typically only used by detractors. The correct claim is: safe Rust eliminates certain classes of bugs. I'd wager the design of std eliminates more (e.g. the different string types), but that doesn't really apply to the kernel. Which is either 1) not true as evidenced by this bug or 2) a tautology whereby Rust eliminates all bugs that it eliminates.
    - PartiallyTyped 10mo ago
      >> safe Rust > 1) not true as evidenced by this bug Code used unsafe, putting us out of "safe" rust.
    - drob518 10mo ago
      I think the answer is #2, the tautology. But just because it’s a tautology doesn’t mean it’s a worthless thing to say. I think it’s also true, for instance (a corollary), that Rust eliminates more types of bugs than C does. And that may be valuable even if it does not mean that Rust eliminates all bugs.
  - lelanthran 10mo ago
bangaladore 10mo ago
Correct me if I'm wrong, but this comment is atleast partially incorrect right? > Since it was in an unsafe block, the error for sure was way easier to find within the codebase than in C. Everything that's not unsafe can be ruled out as a reason for race conditions and the usual memory handling mistakes - that's already a huge win. The benefit of Rust is you can isolate the possible code that causes an XYZ to an unsafe block*. But that doesn't necessarily mean the error shown is directly related to the unsafe block. Like C++, triggering undefined behavior can in theory cause the program to do anything, including fail spectacularly within seemingly unrelated safe code. * Excluding cases where safe things are actually possibly unsafe (like some incorrectly marked FFI)
- malcolmgreaves 10mo ago
  The point at which you _could_ start to have undefined behavior is within an `unsafe` block or function. So even if the "failure" occurred in some "safe" part of the code, the conditions to make that failure would start in the unsafe code. When debugging, we care about where the assumptions we had were violated. Not where we observe a bad effect of these violated assumptions. I think you get here yourself when you say: > triggering undefined behavior can in theory cause the program to do anything, including fail spectacularly within seemingly unrelated safe code The bug isn't where it failed spectacularly. It's where the C++ code triggered undefined behavior. Put another way: if the undefined behavior _didn't_ cause a crash / corrupted data, the bug _still_ exists. We just haven't observed any bad effects from it.
- landr0id 10mo ago
  From my experience UB in Rust can manifest a bit differently than in C or C++, but still generally has enough smoke in the right area. I believe their point was that they only needed to audit only the unsafe blocks to find the actual root cause of the bug once they had an idea of the problematic area.
- lousken 10mo ago
  Why do they allow unsafe parts in linux kernel in the first place? Why rewriting C code into unsafe rust?
troglo-byte 10mo ago
I'll confess I'm a bit less than well-read on this, but I can't help but wonder. How can increasing the number of languages in use within one enormous project possibly reduce critical vulnerabilities over the next decade? If we're looking beyond one decade, then: - As with all other utility, the future must be discounted compared to the present. - A language that might look sterling today might fall behind tomorrow. - Something something AI by 2035.
phendrenad2 10mo ago
I feel like everyone involved in the Linux Kernel Rust world is ironically woefully unaware of how Rust actually works, and what it's actually capable of. I suspect that Rust gurus agree with me, but don't want to say anything because it would hurt Rust adoption in places where it actually is helpful (encryption algorithms...) Kernels - and especially the Linux kernel - are high-performance systems that require lots of shared mutable state. Every driver is a glorified while loop waiting for an IRQ so it can copy a chunk of data from one shared mutable buffer to another shared mutable buffer. So there will need to be some level of unsafe in the code. There's a fallacy that if 95% of the code is safe, and 5% is unsafe, then that code is only 5% as likely to contain memory errors as a comparable C program. But, to reiterate what another commenter said, and something I've predicted for a long time, the tendency for the "unsafe block" to become instrumented by the "safe block" will always exist. People will loosen the API contract between the "safe" and "unsafe" sides until an error in the "safe" side kicks off an error in the "unsafe" side.
- bronson 10mo ago
  > Every driver is a glorified while loop waiting for an IRQ This is so obviously false that I suspect there's the reason you don't see any Rust gurus agreeing with you. Drivers do lots of resource and memory management, far more than just spinning on IRQs.
  - infamouscow 10mo ago
    I should probably ask what experience do you have writing hardware drivers for the Linux kernel, but it's pretty obvious the answer is: none. I actually burst out laughing reading your comment, it's ridiculous. My anecdotal experience interviewing big tech engineers that used Rust reflects GP's hunch about this astonishing experience gap. Just this year, 4/4 candidates I interviewed couldn't give me the correct answer for what two bytes in base 2 represented in base 10. Not a single candidate asked me about the endianness of the system. Now that Rust in the kernel doesn't have an "experimental" escape hatch, these motte-and-bailey arguments aren't going to work. Ultimately, I think this is a good thing for Rust in the kernel. Once all of the idiots and buffoons have been sufficiently derided and ousted from public discourse (deservedly so), we can finally begin having serious and productive technical discussions about how to make C and Rust interoperate in the kernel.
aw1621107 10mo ago
Direct link to the mailing list entry at [0]. The fix for 6.19-rc1 is commit 3e0ae02ba831 [1]. The patch is pretty small (added some extra context since the function it's from is short): 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(); } } And here is the unsafe block mentioned in the commit message with some more context [3]: fn set_cleared(self: &DArc<Self>, abort: bool) -> bool { // <snip> // 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 } [0]: https://lore.kernel.org/linux-cve-announce/2025121614-CVE-2025-68260-558d@gregkh/ https://lore.kernel.org/linux-cve-announce/2025121614-CVE-20... [1]: https://github.com/torvalds/linux/commit/3e0ae02ba831da2b707905f4e602e43f8507b8cc https://github.com/torvalds/linux/commit/3e0ae02ba831da2b707... [2]: https://github.com/torvalds/linux/blob/3e0ae02ba831da2b707905f4e602e43f8507b8cc/drivers/android/binder/node.rs#L536 https://github.com/torvalds/linux/blob/3e0ae02ba831da2b70790... [3]: https://github.com/torvalds/linux/blob/3e0ae02ba831da2b707905f4e602e43f8507b8cc/drivers/android/binder/node.rs#L993 https://github.com/torvalds/linux/blob/3e0ae02ba831da2b70790...
- anon-3988 10mo ago
  The interesting part to me is that this bug does not necessarily happen in an unsafe block. The fix happens in an unsafe block, I think the API should change to avoid this. Perhaps by forcing users to pass a lambda to do stuff instead of having to manually lock and drop?
samdoesnothing 10mo ago
I think it's pretty telling that there are people in this thread trying to pre-empt the expected criticism in this thread. Might be worth thinking why there might be criticism, and why it wouldn't be the case if it was a different language.
n2d4 10mo ago
I recommend you read Greg Koah-Hartman's thread instead of this article: https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM > Rust is is not a "silver bullet" that can solve all security problems, but it sure helps out a lot and will cut out huge swatches of Linux kernel vulnerabilities as it gets used more widely in our codebase. > That being said, we just assigned our first CVE for some Rust code in the kernel: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/ where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall. > Note the other 159 kernel CVEs issued today for fixes in the C portion of the codebase, so as always, everyone should be upgrading to newer kernels to remain secure overall.
- jackrabbit1997 10mo ago
  > > That being said, we just assigned our first CVE for some Rust code in the kernel: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/ https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@g... where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall. That indicates that Greg Koah-Hartman has a very poor understanding of Rust and the _unsafe_ keyword. The bug can, in fact, exhibit undefined behavior and memory corruption. His lack of understanding is unfortunate, to put it very mildly.
  - n2d4 10mo ago
    What are some compiler flags that would compile the code such that an attacker could take advantage? And what would the attack be? Or is this just a theoretical argument, "it is hypothetically possible to create a technically-spec-compliant Rust compiler that would compile this into dangerous machine code"? If so it should still be fixed of course, but if I'm patching my Linux kernel I'd rather know what the practical impact is.
    - aw1621107 10mo ago
      To play a bit of devil's advocate, I don't think the problem is necessarily with the compiler output. It's more that it's not always easy to definitively state the precise consequences of a particular issue, especially when it comes to memory safety-/UB-related issues. For example, consider this Project Zero writeup about using a single NUL byte buffer overflow as part of a root privilege exploit [0] despite some skepticism about whether that overflow was actually exploitable. To be fair, I'm not saying that Greg KH is definitely wrong; I'm only willing to claim that in the general case observing crashes due to corrupted pointers does not necessarily mean that there's no ability to actually exploit said corruption. Actual exploitability will depend on other factors as well, and I'm far from knowledgeable enough to say anything on the matter. [0]: https://projectzero.google/2014/08/the-poisoned-nul-byte-2014-edition.html https://projectzero.google/2014/08/the-poisoned-nul-byte-201...
uecker 10mo ago
Somebody (tsoding?) called "unsafe" in Rust a "blame shifting device". If a bug was in an "unsafe" block, it is not Rust's fault, but solely the responsibility of the programmer, while every bug in a C program is obviously the language's fault alone.
- K0nserv 10mo ago
  Everything is solely the responsibility of the programmer. The strength of Rust as a language is that it helps the programmer check themselves before they wreck themselves. The critique of C would be that it provides far too little support to the programmer, although it was reasonable at the time it was was invented. Unsafe is the one escape hatch where Rust is more like C, but pragmatically it's an important escape hatch.
  - uecker 10mo ago
    Yes, but the arguments why we need to replace C code with Rust was not that it is better by "helping the programmer check themselves" but that we need to switch to memory-safe languages because it "removes a whole class of error". (of course, nobody has ever said this, this must be my imagination) Finally, there are also a lot of ways to improve memory safety in C which are not nowhere exhausted even in the kernel. As long as this is not even the case, I find the argument that there is "too little support for the programmer" quite hollow.
    - K0nserv 10mo ago
      > Yes, but the arguments why we need to replace C code with Rust was not that it is better by "helping the programmer check themselves" but that we need to switch to memory-safe languages because it "removes a whole class of error". (of course, nobody has ever said this, this must be my imagination) Rust being memory safe is a way in which it helps the programmer check themselves. Absolute statements like "removes a whole class of error" are dangerous, there are always caveats. Rust seems to be doing a heck of a good job at this particular task, even if it sometimes falls short. > Finally, there are also a lot of ways to improve memory safety in C which are not nowhere exhausted even in the kernel. As long as this is not even the case, I find the argument that there is "too little support for the programmer" quite hollow. The kernel has been under the development for north of 30 years at this point. These ways to improve safety in C don't seem to be materialising.
mimd 10mo ago
Huzzah! You made it to the big leagues Rust! Come join C over here with the "CookiesVE".
jackrabbit1997 10mo ago
[flagged]
- woodruffw 10mo ago
  [flagged]
Joel_LeBlanc 10mo ago
It's great to see discussions around the intricacies of digital assets, especially when it comes to security like the CVE vulnerabilities in the Linux kernel. I've been in the digital asset space for a while, and I always emphasize the importance of thorough due diligence—it's a bit of a balancing act knowing that bugs can arise. For evaluating apps specifically, I’ve found the DREA (Digital Real Estate Analyzer) tool really helpful for assessing potential risks and opportunities. It’s all about being prepared while recognizing that the digital landscape can be unpredictable.

129 points by weinzierl 10mo ago

Now we have vulnerabilities in two different flavors.

"That code can lead to memory corruption of the previous/next pointers and in turn cause a crash." Oh no, what happened to Rust will save us from retarded legacy languages prone to memory corruption?

gfna 10mo ago
Well the article did mention it was in an undafe block
- greatgib 10mo ago
  1) unsafe block still of "rust" code that rewritten in "rust" to be safe compared to previous C code. 2) Maybe there is no other way than use "unsafe" block sometimes in "rust", so is Rust a lie?
  - AndrewDucker 10mo ago
    Rust constrains the code that can do unsafe things to small blocks, greatly reducing the area in which they can happen. Unlike C, where the whole of the code is unsafe.
  - gitaarik 10mo ago
    I imagine for some very low level kernel stuff, you might want to turn off Rust's safety features because they get in the way, make things less efficient or something. But then when you do you should really know what you're doing. The fact that this bug is because of "unsafe" Rust usage actually affirms the language's safety when using "safe" code. Although with "memory safe" code you can of course still fuck up lots of other things.
deleted 10mo ago
[deleted]
techbrovanguard 10mo ago
If you do something stupid in a block marked "unsafe", it's probably on you, my guy.

pa7ch 10mo ago

Honestly seems like zig is shaping up to be a better fit for kernel. Regardless the language that attracts skilled kernel devs will matter more then lang.

postepowanieadm 10mo ago
It's true only for unsafe rust.
ameixaseca 10mo ago
It is not - and given its stance on memory safety, it will hardly ever be.
dralley 10mo ago
Rust has been stable for 10 years. Zig is still not stable.

HumanOstrich 10mo ago

They're still 90% of the way to their goal. And there's only 90% left to go.

tekacs 10mo ago

To pre-empt the folks who'll come in here and laugh about how Rust should be preventing memory corruption... I'll just directly quote from the mailing list: Rust Binder contains the following unsafe operation: // 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) }; This operation is unsafe because when touching the prev/next pointers of a list element, we have to ensure that no other thread is also touching them in parallel. If the node is present in the list that `remove` is called on, then that is fine because we have exclusive access to that list. If the node is not in any list, then it's also ok. But if it's present in a different list that may be accessed in parallel, then that may be a data race on the prev/next pointers. And unfortunately that is exactly what is happening here. In Node::release, we: 1. Take the lock. 2. Move all items to a local list on the stack. 3. Drop the lock. 4. Iterate the local list on the stack. Combined with threads using the unsafe remove method on the original list, this leads to memory corruption of the prev/next pointers. This leads to crashes like this one:

samdoesnothing 10mo ago
If rust is so inflexible that it requires the use of unsafe to solve problems, that's still rust's fault. You have to consider both safe rust behaviour as well as necessary unsafe code.
- woodruffw 10mo ago
  This is sort of the exact opposite of reality: the point of safe Rust is that it's safe so long as Rust's invariants are preserved, which all other safe Rust preserves by construction. So you only need to audit unsafe Rust code to ensure the safety of a Rust codebase. (The nuance being that sometimes there's a lot of unsafe Rust, because some domains - like kernel programming - necessitate it. But this is still a better state of affairs than having no code be correct by construction, which is the reality with C.)
  - gkbrk 10mo ago

secondcoming 10mo ago

[flagged]

drob518 10mo ago

Anybody who thought the simple action of rewriting things in Rust would eliminate all bugs was hopelessly naive. Particularly since Rust allows unsafe operations. That doesn’t mean Rust provides no value over C, just that the value is short of total elimination of bugs. Which was never advertised as the value to begin with.

zamalek 10mo ago
> Anybody who thought the simple action of rewriting things in Rust would eliminate all bugs was hopelessly naive All bugs is typically a strawman typically only used by detractors. The correct claim is: safe Rust eliminates certain classes of bugs. I'd wager the design of std eliminates more (e.g. the different string types), but that doesn't really apply to the kernel.
- samdoesnothing 10mo ago
  > All bugs is typically a strawman typically only used by detractors. The correct claim is: safe Rust eliminates certain classes of bugs. I'd wager the design of std eliminates more (e.g. the different string types), but that doesn't really apply to the kernel. Which is either 1) not true as evidenced by this bug or 2) a tautology whereby Rust eliminates all bugs that it eliminates.
  - PartiallyTyped 10mo ago
    >> safe Rust > 1) not true as evidenced by this bug Code used unsafe, putting us out of "safe" rust.
  - drob518 10mo ago
    I think the answer is #2, the tautology. But just because it’s a tautology doesn’t mean it’s a worthless thing to say. I think it’s also true, for instance (a corollary), that Rust eliminates more types of bugs than C does. And that may be valuable even if it does not mean that Rust eliminates all bugs.
- lelanthran 10mo ago

bangaladore 10mo ago

Correct me if I'm wrong, but this comment is atleast partially incorrect right? > Since it was in an unsafe block, the error for sure was way easier to find within the codebase than in C. Everything that's not unsafe can be ruled out as a reason for race conditions and the usual memory handling mistakes - that's already a huge win. The benefit of Rust is you can isolate the possible code that causes an XYZ to an unsafe block*. But that doesn't necessarily mean the error shown is directly related to the unsafe block. Like C++, triggering undefined behavior can in theory cause the program to do anything, including fail spectacularly within seemingly unrelated safe code. * Excluding cases where safe things are actually possibly unsafe (like some incorrectly marked FFI)

malcolmgreaves 10mo ago
The point at which you _could_ start to have undefined behavior is within an `unsafe` block or function. So even if the "failure" occurred in some "safe" part of the code, the conditions to make that failure would start in the unsafe code. When debugging, we care about where the assumptions we had were violated. Not where we observe a bad effect of these violated assumptions. I think you get here yourself when you say: > triggering undefined behavior can in theory cause the program to do anything, including fail spectacularly within seemingly unrelated safe code The bug isn't where it failed spectacularly. It's where the C++ code triggered undefined behavior. Put another way: if the undefined behavior _didn't_ cause a crash / corrupted data, the bug _still_ exists. We just haven't observed any bad effects from it.
landr0id 10mo ago
From my experience UB in Rust can manifest a bit differently than in C or C++, but still generally has enough smoke in the right area. I believe their point was that they only needed to audit only the unsafe blocks to find the actual root cause of the bug once they had an idea of the problematic area.
lousken 10mo ago
Why do they allow unsafe parts in linux kernel in the first place? Why rewriting C code into unsafe rust?

troglo-byte 10mo ago

I'll confess I'm a bit less than well-read on this, but I can't help but wonder. How can increasing the number of languages in use within one enormous project possibly reduce critical vulnerabilities over the next decade? If we're looking beyond one decade, then: - As with all other utility, the future must be discounted compared to the present. - A language that might look sterling today might fall behind tomorrow. - Something something AI by 2035.

phendrenad2 10mo ago

I feel like everyone involved in the Linux Kernel Rust world is ironically woefully unaware of how Rust actually works, and what it's actually capable of. I suspect that Rust gurus agree with me, but don't want to say anything because it would hurt Rust adoption in places where it actually is helpful (encryption algorithms...) Kernels - and especially the Linux kernel - are high-performance systems that require lots of shared mutable state. Every driver is a glorified while loop waiting for an IRQ so it can copy a chunk of data from one shared mutable buffer to another shared mutable buffer. So there will need to be some level of unsafe in the code. There's a fallacy that if 95% of the code is safe, and 5% is unsafe, then that code is only 5% as likely to contain memory errors as a comparable C program. But, to reiterate what another commenter said, and something I've predicted for a long time, the tendency for the "unsafe block" to become instrumented by the "safe block" will always exist. People will loosen the API contract between the "safe" and "unsafe" sides until an error in the "safe" side kicks off an error in the "unsafe" side.

bronson 10mo ago
> Every driver is a glorified while loop waiting for an IRQ This is so obviously false that I suspect there's the reason you don't see any Rust gurus agreeing with you. Drivers do lots of resource and memory management, far more than just spinning on IRQs.
- infamouscow 10mo ago
  I should probably ask what experience do you have writing hardware drivers for the Linux kernel, but it's pretty obvious the answer is: none. I actually burst out laughing reading your comment, it's ridiculous. My anecdotal experience interviewing big tech engineers that used Rust reflects GP's hunch about this astonishing experience gap. Just this year, 4/4 candidates I interviewed couldn't give me the correct answer for what two bytes in base 2 represented in base 10. Not a single candidate asked me about the endianness of the system. Now that Rust in the kernel doesn't have an "experimental" escape hatch, these motte-and-bailey arguments aren't going to work. Ultimately, I think this is a good thing for Rust in the kernel. Once all of the idiots and buffoons have been sufficiently derided and ousted from public discourse (deservedly so), we can finally begin having serious and productive technical discussions about how to make C and Rust interoperate in the kernel.

aw1621107 10mo ago

Direct link to the mailing list entry at [0]. The fix for 6.19-rc1 is commit 3e0ae02ba831 [1]. The patch is pretty small (added some extra context since the function it's from is short): 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(); } } And here is the unsafe block mentioned in the commit message with some more context [3]: fn set_cleared(self: &DArc<Self>, abort: bool) -> bool { // <snip> // 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 } [0]: https://lore.kernel.org/linux-cve-announce/2025121614-CVE-2025-68260-558d@gregkh/ https://lore.kernel.org/linux-cve-announce/2025121614-CVE-20... [1]: https://github.com/torvalds/linux/commit/3e0ae02ba831da2b707905f4e602e43f8507b8cc https://github.com/torvalds/linux/commit/3e0ae02ba831da2b707... [2]: https://github.com/torvalds/linux/blob/3e0ae02ba831da2b707905f4e602e43f8507b8cc/drivers/android/binder/node.rs#L536 https://github.com/torvalds/linux/blob/3e0ae02ba831da2b70790... [3]: https://github.com/torvalds/linux/blob/3e0ae02ba831da2b707905f4e602e43f8507b8cc/drivers/android/binder/node.rs#L993 https://github.com/torvalds/linux/blob/3e0ae02ba831da2b70790...

anon-3988 10mo ago
The interesting part to me is that this bug does not necessarily happen in an unsafe block. The fix happens in an unsafe block, I think the API should change to avoid this. Perhaps by forcing users to pass a lambda to do stuff instead of having to manually lock and drop?

samdoesnothing 10mo ago

I think it's pretty telling that there are people in this thread trying to pre-empt the expected criticism in this thread. Might be worth thinking why there might be criticism, and why it wouldn't be the case if it was a different language.

n2d4 10mo ago

I recommend you read Greg Koah-Hartman's thread instead of this article: https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM > Rust is is not a "silver bullet" that can solve all security problems, but it sure helps out a lot and will cut out huge swatches of Linux kernel vulnerabilities as it gets used more widely in our codebase. > That being said, we just assigned our first CVE for some Rust code in the kernel: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/ where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall. > Note the other 159 kernel CVEs issued today for fixes in the C portion of the codebase, so as always, everyone should be upgrading to newer kernels to remain secure overall.

jackrabbit1997 10mo ago
> > That being said, we just assigned our first CVE for some Rust code in the kernel: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/ https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@g... where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall. That indicates that Greg Koah-Hartman has a very poor understanding of Rust and the _unsafe_ keyword. The bug can, in fact, exhibit undefined behavior and memory corruption. His lack of understanding is unfortunate, to put it very mildly.
- n2d4 10mo ago
  What are some compiler flags that would compile the code such that an attacker could take advantage? And what would the attack be? Or is this just a theoretical argument, "it is hypothetically possible to create a technically-spec-compliant Rust compiler that would compile this into dangerous machine code"? If so it should still be fixed of course, but if I'm patching my Linux kernel I'd rather know what the practical impact is.
  - aw1621107 10mo ago
    To play a bit of devil's advocate, I don't think the problem is necessarily with the compiler output. It's more that it's not always easy to definitively state the precise consequences of a particular issue, especially when it comes to memory safety-/UB-related issues. For example, consider this Project Zero writeup about using a single NUL byte buffer overflow as part of a root privilege exploit [0] despite some skepticism about whether that overflow was actually exploitable. To be fair, I'm not saying that Greg KH is definitely wrong; I'm only willing to claim that in the general case observing crashes due to corrupted pointers does not necessarily mean that there's no ability to actually exploit said corruption. Actual exploitability will depend on other factors as well, and I'm far from knowledgeable enough to say anything on the matter. [0]: https://projectzero.google/2014/08/the-poisoned-nul-byte-2014-edition.html https://projectzero.google/2014/08/the-poisoned-nul-byte-201...

uecker 10mo ago

Somebody (tsoding?) called "unsafe" in Rust a "blame shifting device". If a bug was in an "unsafe" block, it is not Rust's fault, but solely the responsibility of the programmer, while every bug in a C program is obviously the language's fault alone.

K0nserv 10mo ago
Everything is solely the responsibility of the programmer. The strength of Rust as a language is that it helps the programmer check themselves before they wreck themselves. The critique of C would be that it provides far too little support to the programmer, although it was reasonable at the time it was was invented. Unsafe is the one escape hatch where Rust is more like C, but pragmatically it's an important escape hatch.
- uecker 10mo ago
  Yes, but the arguments why we need to replace C code with Rust was not that it is better by "helping the programmer check themselves" but that we need to switch to memory-safe languages because it "removes a whole class of error". (of course, nobody has ever said this, this must be my imagination) Finally, there are also a lot of ways to improve memory safety in C which are not nowhere exhausted even in the kernel. As long as this is not even the case, I find the argument that there is "too little support for the programmer" quite hollow.
  - K0nserv 10mo ago
    > Yes, but the arguments why we need to replace C code with Rust was not that it is better by "helping the programmer check themselves" but that we need to switch to memory-safe languages because it "removes a whole class of error". (of course, nobody has ever said this, this must be my imagination) Rust being memory safe is a way in which it helps the programmer check themselves. Absolute statements like "removes a whole class of error" are dangerous, there are always caveats. Rust seems to be doing a heck of a good job at this particular task, even if it sometimes falls short. > Finally, there are also a lot of ways to improve memory safety in C which are not nowhere exhausted even in the kernel. As long as this is not even the case, I find the argument that there is "too little support for the programmer" quite hollow. The kernel has been under the development for north of 30 years at this point. These ways to improve safety in C don't seem to be materialising.

mimd 10mo ago

Huzzah! You made it to the big leagues Rust! Come join C over here with the "CookiesVE".

jackrabbit1997 10mo ago

[flagged]

woodruffw 10mo ago
[flagged]

Joel_LeBlanc 10mo ago

It's great to see discussions around the intricacies of digital assets, especially when it comes to security like the CVE vulnerabilities in the Linux kernel. I've been in the digital asset space for a while, and I always emphasize the importance of thorough due diligence—it's a bit of a balancing act knowing that bugs can arise. For evaluating apps specifically, I’ve found the DREA (Digital Real Estate Analyzer) tool really helpful for assessing potential risks and opportunities. It’s all about being prepared while recognizing that the digital landscape can be unpredictable.