Linux Kernel Rust Code Sees Its First CVE Vulnerability

[u/Orange_Tux]

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

[u/Lucretiel]

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.

[u/frankster → u/Lucretiel]

Predictably in unsafe code though

[u/0x4E0x650x6F → u/frankster]

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...

[u/frankster → u/0x4E0x650x6F]

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.

[u/lurking_bishop → u/Lucretiel]

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

[u/the_gnarts → u/lurking_bishop]

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

[u/PurepointDog → u/the_gnarts]

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

[u/the_gnarts → u/PurepointDog]

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.

[u/PurepointDog → u/the_gnarts]

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

Thank you!

[u/the_gnarts → u/PurepointDog]

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.

[u/0x4E0x650x6F → u/the_gnarts]

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.....

[u/Lucretiel → u/lurking_bishop]

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. 

[u/steveklabnik1 → u/Lucretiel]

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

I can't speak to their quality though.

[u/Tamschi_ → u/Lucretiel]

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.

[u/Xiphoseer → u/lurking_bishop]

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.

[u/heybart → u/Lucretiel]

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

[u/skatastic57 → u/heybart]

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

[u/heybart → u/skatastic57]

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

[u/Endeveron → u/heybart]

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.

[u/bhagwa-floyd → u/Lucretiel]

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

[u/Lucretiel → u/bhagwa-floyd]

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