Eerste CVE voor Rust-code in Linux kernel: race condition in binder driver, geen memory corruption

De Linux kernel heeft zijn eerste officiële CVE (Common Vulnerabilities and Exposures) gekregen voor een bug in Rust-code – een milestone die zowel symbolisch als technisch relevant is. Greg Kroah-Hartman, een van de core maintainers van de kernel, bevestigt dat CVE-2025-68260 is toegewezen aan een race condition in de rust-binder driver. De bug kan een kernel crash veroorzaken, maar – en dit is cruciaal – het gaat niet om memory corruption, het type vulnerability waar Rust juist voor ontworpen is om te voorkomen.

Dit is niet de eerste bug in Rust-code in de kernel (die zijn er altijd geweest), maar wel de eerste die formeel getracked wordt met een CVE-nummer. Ter context: er zijn in dezelfde periode 159 andere CVE’s toegewezen aan kernel-code, maar die zijn allemaal in C. Dat Rust nu één CVE heeft na 3 jaar experimentele integratie (sinds 2022), terwijl C-code er 159 heeft in vergelijkbare timeframe, onderstreept waarom Rust als veiliger alternatief wordt gezien.

CVE-2025-68260: race condition, geen memory bug

Wat is er precies mis?

De vulnerability zit in de rust-binder driver, een Rust-reimplementatie van Android’s Binder IPC (Inter-Process Communication) mechanisme. Binder is kritiek voor Android’s architecture – het handelt communicatie tussen apps en system services.

Race condition betekent:

• Twee of meer threads/processes proberen simultaan dezelfde resource te benaderen
• Door timing issues kan de internal state inconsistent worden
• In dit geval: kan leiden tot kernel panic (crash)

Belangrijke nuance: dit is GEEN memory safety bug. Rust’s ownership model en borrow checker voorkomen:

• Use-after-free (toegang tot geheugen dat al vrijgegeven is)
• Double-free (twee keer hetzelfde geheugen vrijgeven)
• Buffer overflows (schrijven buiten toegewezen geheugenblok)
• Null pointer dereferences (toegang tot invalid memory addresses)

Maar Rust voorkomt niet automatisch:

• Logic errors (verkeerde algoritme-implementatie)
• Race conditions (zonder explicit synchronization primitives zoals Mutex, RwLock)
• Deadlocks (threads die op elkaar wachten)

Deze CVE bewijst dat Rust niet magisch alle bugs elimineert – het elimineert een specifieke klasse (memory safety), maar developers kunnen nog steeds concurrency-bugs maken als ze threading/locking verkeerd doen.

Waarom is dit de eerste Rust-CVE maar zijn er 159 C-CVE’s?

Context is key:

Rust in de kernel: minimale codebase

• Rust is sinds 2022 experimenteel toegevoegd
• Totale Rust-code in kernel: ~100k lines (schatting)
• Totale C-code in kernel: ~30 miljoen lines
• Rust is dus <0.5% van de totale kernel-codebase

Exposure ratio:

• 1 CVE in ~100k lines Rust = 1 per 100k
• 159 CVE’s in ~30M lines C = ~5 per 100k (in vergelijkbare periode)

Dit is rough math (niet exact dezelfde tijdspanne), maar het illustreert dat Rust’s vulnerability density lager is – zelfs met minder mature tooling en minder developer-ervaring.

Rust-code is nog grotendeels in “safe” drivers

De Rust-implementaties in de kernel zijn voornamelijk:

• Device drivers (binder, NVMe, etc.)
• Filesysteem abstractions
• Networking components (experimenteel)

Dit zijn relatief geïsoleerde subsystemen – niet de core memory management, scheduler, of security-critical paths. Als Rust verder penetreert in kernel-core, zal het aantal CVE’s waarschijnlijk groeien (gewoon omdat meer code = meer bugs), maar de rate zou lager moeten blijven dan C.

Greg Kroah-Hartman’s perspectief: “redelijk uniek”

Kroah-Hartman noemt het “fairly unique” dat er een Rust-CVE is, wat je kunt interpreteren als:

1. Positief: Het is zeldzaam omdat Rust zo weinig serious bugs heeft 2. Neutraal: Het is gewoon statistisch onvermijdelijk – elke codebase krijgt uiteindelijk CVE’s 3. Reality-check: Rust is geen silver bullet – race conditions blijven mogelijk

Zijn tone suggereert vooral pragmatisch realisme: Rust helpt enorm met memory safety, maar developers moeten nog steeds correct concurrency-design doen. De borrow checker dwingt geen lock-strategies af – dat is nog steeds developer-verantwoordelijkheid.

Miguel Ojeda: “Rust is een blijvertje”

Eerder deze week herbevestigde Miguel Ojeda, lead developer van Rust-for-Linux project, dat Rust permanent blijft in de kernel. Dit is significant omdat er in 2024 interne strijd was tussen:

Pro-Rust faction:

• Memory safety is critical (70% van kernel CVE’s zijn memory-related)
• Modern tooling en type-safety verbeteren code quality
• Future-proofing: nieuwe developers prefereren Rust over C

C-purists faction:

• Rust is “hype” en onnodige complexiteit
• C is “good enough” als developers careful zijn
• Build-times en toolchain-dependencies zijn problematisch

Ojeda’s statement, en Linus Torvalds’ continued support, maken duidelijk dat Rust blijft – ondanks weerstand van sommige maintainers.

Waarom race conditions moeilijker te voorkomen zijn (zelfs in Rust)

Rust’s ownership model voorkomt data races op compile-time via:

Borrow checker rules:

• Je kunt één mutable reference OF meerdere immutable references hebben, nooit beide
• Dit voorkomt dat thread A schrijft terwijl thread B leest (data race)

Maar logic-level race conditions zijn anders:

Voorbeeld:

rust

// Thread A
if !is_locked() {  // Check
    do_operation(); // Use
}

// Thread B
lock();            // Changes state tussen check en use in Thread A

Dit is een TOCTOU (Time-Of-Check-Time-Of-Use) race – niet een data race. Rust’s compiler kan dit niet detecteren omdat het semantisch correct is: geen overlappende mutable/immutable borrows. Maar logisch is het een bug.

Hoe had dit voorkomen kunnen worden?

1. Gebruik Mutex/RwLock

rust

let data = Mutex::new(state);
let guard = data.lock().unwrap(); // Atomic check+lock
// Safe operations here

2. Atomic operations Voor simpele flags: AtomicBool, AtomicU64 etc. voorkomen races zonder locks.

3. Formal verification Tools zoals Miri (Rust’s interpreter die undefined behavior detecteert) kunnen sommige races vinden, maar niet alle logic-level issues.

De binder-driver bug was waarschijnlijk een missing lock of incorrect locking order – iets dat code review had kunnen vangen, maar door slipte.

Impact: wie wordt geraakt door CVE-2025-68260?

Directe impact: minimaal

• Android devices die Rust-binder gebruiken (experimenteel, niet production default)
• Linux systems met custom kernels die Rust-binder enabled hebben
• Meeste users draaien C-based binder of geen binder (niet-Android systems)

Severity: low-to-medium

• Kan kernel crash veroorzaken (DoS, geen code execution)
• Geen privilege escalation (attacker kan niet root worden)
• Geen data leakage (geen memory corruption die secrets exposed)

Fix: waarschijnlijk simpel

Race conditions fixen is meestal:

• Add missing lock
• Reorder locking sequence
• Use atomic operations

Patch is waarschijnlijk <10 lines of code. Veel minder complex dan memory corruption fixes in C (die vaak architecture redesigns vereisen).

Vergelijking: Rust vs C vulnerability-types

Typische C kernel CVE’s (memory-related):

• Use-after-free (35% van kernel CVE’s)
• Buffer overflow (25%)
• Null pointer dereference (15%)
• Double-free (10%)

Rust elimineert bovenstaande bijna volledig

Wat Rust NIET voorkomt:

• Logic errors (verkeerde algoritme)
• Race conditions (concurrency bugs)
• Resource leaks (file descriptors, sockets – Rust helpt wel met RAII maar voorkomt niet alle leaks)
• Denial of service (infinite loops, excessive memory allocation)

CVE-2025-68260 is race condition – een categorie waar Rust helpt (via Send/Sync traits en borrow checker), maar niet foolproof is.

Community reacties: “told you so” van beide kanten

Pro-Rust side:

• “1 CVE in 3 jaar vs 159 in C – case closed”
• “And it’s not even a memory bug, proves Rust’s value”
• “Imagine if binder was in C, we’d have 10+ memory corruption CVEs by now”

C-purist side:

• “See, Rust doesn’t prevent all bugs, overhyped”
• “Race conditions are just as bad as memory bugs”
• “We could write safe C if we had better review processes”

Pragmatic middle:

• “This is expected – Rust reduces memory bugs, not logic bugs”
• “The ratio (1 vs 159) speaks for itself”
• “We need Rust AND better review practices”

Toekomst: meer Rust in kernel = meer CVE’s, maar lagere rate

Predictie:

2025-2026:

• Rust-codebase groeit naar 500k-1M lines
• Verwacht 5-10 Rust CVE’s per jaar
• C blijft 100-200 CVE’s per jaar

Rate vergelijking:

• Rust: ~10 CVE’s / 1M lines = 10 per million
• C: ~200 CVE’s / 30M lines = ~7 per million (maar veel zijn repeats/similar bugs)

Wait, is C dus beter? Nee, want:

• C’s CVE’s zijn disproportioneel memory-bugs (high severity)
• Rust’s CVE’s zullen voornamelijk logic/concurrency bugs zijn (medium severity)
• Exploitability: memory bugs → code execution; logic bugs → meestal crashes/DoS

Lessen voor Rust-in-Linux project

1. Concurrency review needs emphasis

• Focus niet alleen op memory safety tijdens code review
• Besteed expliciete aandacht aan threading/locking patterns
• Tooling: integreer loom (concurrency testing lib) in CI

2. Fuzzing aanpassen

• Memory fuzzing (AFL, libFuzzer) werkt goed voor C
• Voor Rust: concurrency fuzzing (stress-test multi-threaded scenarios)
• Miri in CI voor undefined behavior checks

3. Developer training

• Rust voorkomt memory bugs automatisch, maar concurrency must be learned
• Training materials over Mutex, RwLock, Arc, atomic types
• Code review checklists specifiek voor concurrency

4. Blame-free postmortems

• Dit is NIET “Rust failed” – het is “developer made logic error”
• Leer van de bug, improve processes
• Celebrate dat het geen memory corruption was

Politieke implicaties: ammunition voor beide kanten

Anti-Rust maintainers: “Zie je wel, Rust is geen wondermiddel, we hadden dit kunnen hebben in C met goede review”

Pro-Rust advocates: “Exactly – dit is wat we verwachtten: logic bugs blijven, maar memory bugs verdwijnen”

Linus Torvalds (waarschijnlijk): silence – hij is pragmatisch: als Rust crashes vermindert over tijd, blijft het; als niet, wordt het geëvalueerd.

De echte test is over 2-3 jaar: als Rust 10%+ van kernel is, en CVE-rate nog steeds lager dan C, is het bewezen. Tot die tijd blijft het experiment met positieve early indicators.

Conclusie: milestone, geen crisis

CVE-2025-68260 is een normaal onderdeel van software development – bugs happen, CVE’s worden toegewezen, patches worden uitgerold. Het is alleen interessant omdat:

1. Het is de eerste Rust-CVE in een high-profile project (Linux kernel) 2. Het bevestigt verwachtingen: Rust stopt memory bugs, niet logic bugs **3. De ratio (1 vs 159) valideert Rust’s veiligheids-claims

Voor het Rust-in-Linux project: business as usual. Fix de bug, leer ervan, improve tooling/processes.

Voor de industrie: nog een datapunt dat Rust measurably safer is voor systems programming, maar geen magic wand.

Voor kernel developers: blijf focussen op both memory safety EN concurrency correctness – Rust helpt met het eerste, maar het tweede blijft hard work.

En voor Greg Kroah-Hartman: waarschijnlijk terug naar de andere 158 C-CVE’s die ook aandacht nodig hebben. Rust mag dan veiliger zijn, C blijft 99.5% van de kernel – en dat is waar de meeste vulnerabilities zitten.