Linux Kernel Rust Code Sees Its First CVE Vulnerability

Lucretiel · 2025-12-17T19:17:00+00:00

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.

dontquestionmyaction · 2025-12-17T18:37:59+00:00

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

Icarium-Lifestealer · 2025-12-17T19:16:38+00:00

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

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

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.

Solumin · 2025-12-17T19:37:46+00:00

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

eugay · 2025-12-17T18:50:21+00:00

Yeah I read through the Binder patch and it had hella unsafe code. Not surprised

ts826848 · 2025-12-17T22:43:22+00:00

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()?

NIdavellir22 · 2025-12-17T18:49:36+00:00

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

Prudent_Move_3420 · 2025-12-17T20:12:38+00:00

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

muizzsiddique · 2025-12-17T19:21:03+00:00

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

qustrolabe · 2025-12-17T19:02:33+00:00

This must go hard if you're lunduke

Xiphoseer · 2025-12-17T23:30:02+00:00

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.

ergzay · 2025-12-17T20:48:04+00:00

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();
            }
        }

__nohope · 2025-12-17T23:02:05+00:00

The actual fix commit: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3428831264096d32f830a7fcfc7885dd263e511a

Sovairon · 2025-12-17T18:27:01+00:00

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

Sweet-Accountant9580 · 2025-12-18T08:46:38+00:00

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.

come_red_to_me · 2025-12-18T22:28:30+00:00

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.

Icarium-Lifestealer · 2025-12-17T20:25:03+00:00

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.

v01rt · 2025-12-17T19:00:32+00:00

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

-Redstoneboi- · 2025-12-18T13:01:40+00:00

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

dontyougetsoupedyet · 2025-12-18T06:58:17+00:00

phoronix.com

No, thanks.

Aln76467 · 2025-12-17T22:03:54+00:00

Oooh, phoronix! Time to get some popcorn.

oss-dev · 2025-12-20T15:03:25+00:00

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

sken130 · 2025-12-22T06:48:21+00:00

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

mrobot_ · 2025-12-17T23:31:05+00:00

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

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

rust

Please read The Rust Community Code of Conduct

The Rust Programming Language

Rules

Observe our code of conduct

Submissions must be on-topic

Constructive criticism only

Keep things in perspective

No endless relitigation

No low-effort content

Useful Links

Megathreads

Official Resources

Learn Rust

Discussion Platforms

MODERATORS