Linux Kernel Rust Code Sees Its First CVE Vulnerability

Nature of the Bug

• CVE is in Linux’s Rust Binder code, specifically a concurrent doubly linked list.
• Root cause: misuse of an unsafe List::remove on a node that might be in a different list concurrently, corrupting prev/next pointers and causing crashes.
• Fix changes logic to process the list under the lock in a loop rather than moving it out and iterating without the lock.
• Some argue the underlying list API is a “footgun” and should be replaced with a safer data structure or API shape.

Unsafe Rust and the Safety Model

• Many emphasize: the bug is in unsafe Rust, not safe Rust, which is exactly where memory-unsafe behavior is supposed to be possible.
• Rust’s promise is characterized as: safe Rust eliminates entire classes of memory bugs, and all memory-unsafe bugs must originate in unsafe blocks or functions.
• Others counter that the boundary is not as clean: unsafe blocks can depend on invariants enforced by surrounding safe code, so entire modules sometimes need auditing.

Expectations and “If It Compiles It Works”

• Debate over Rust evangelism:
  • Critics claim there has been a “motte and bailey” shift from “if it compiles it works” / “memory bugs go away” to a weaker “safer than C”.
  • Defenders say “all bugs” was always a strawman; the real claim is about specific classes (memory safety, aliasing, ownership).
• Several note the experiential sense that Rust code that compiles tends to be much closer to correct, but no one seriously promises logical correctness.

Rust vs C (and Zig) in the Kernel

• Some suggest Zig or plain C might be more natural for kernels given pervasive shared mutable state and concurrency.
• Others argue the kernel is exactly where Rust’s constrained unsafe regions are most valuable: C is effectively a single giant unsafe {}.
• There’s discussion over how much kernel code truly must be unsafe; some think this particular list code could have been safe Rust.

Auditing, CVEs, and Metrics

• One commenter highlights that this single Rust CVE appeared alongside 159 C CVEs in the same batch.
• Debate over whether raw CVE counts or per-LOC normalization meaningfully measure language safety, especially given only ~0.3% of kernel code is Rust and most Rust relies on some unsafe in its dependency tree.
• Viewpoints split between “Rust clearly reduces bug surface” and “impact is real but less dramatic than advertised.”

Process, SAFETY Comments, and API Design

• SAFETY comments near unsafe blocks are meant to document invariants; here, the documented invariant was incomplete (focused on ownership, not concurrency).
• Concern that reviewers may over-trust SAFETY comments rather than re-deriving invariants.
• Some argue this is a process failure, not a Rust failure, but still a warning that unsafe sections need “extreme scrutiny.”
• A few see unsafe as a “blame shifting device”; others reply that all bugs are ultimately programmer responsibility, and Rust merely narrows where to look.

Mixed-Language Kernel and Long-Term Outlook

• Questions raised about adding another language to the kernel: will complexity outweigh safety benefits over a decade?
• Counterpoint: you need unsafe Rust for kernel FFI and low-level operations now, but as Rust subsystems grow, more code can be safe, and C becomes the FFI edge.
• General consensus: this CVE was predictable once unsafe Rust entered the kernel; the real question is whether overall bug volume and severity drop compared to all-C code.