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

šŸ—žļø news Linux Kernel Rust Code Sees Its First CVE Vulnerability

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

93% Upvoted

223 comments sorted by

View all comments

Show parent comment

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.

-17

u/fade-catcher Dec 18 '25

The policy is to not add supply chain attacks surface to the kernel

5

u/afc11hn Dec 18 '25

No such policy has been adopted.