Die erste Rust-Linux-Kernel-CVE ist da

Kritiker bezeichnen CVE-2025-68260 als Fehlschlag. Hier ist der Grund, warum sie in Wirklichkeit die bisher stärkste Bestätigung für Rust ist.


Wenn du diese Woche auf Hacker News oder r/rust unterwegs warst, hast du die Schlagzeilen gesehen. Der Himmel fällt herunter. Der Traum von "Rewrite It In Rust" ist tot.

CVE-2025-68260 ist offiziell erschienen – die erste größere Sicherheitslücke, die Rust-Code im Linux-Kernel zugeordnet wurde.

Die Schwachstelle wurde im Modul rust_binder gefunden (der in Rust neu geschriebene Android-Binder-Treiber). Es handelt sich um eine Race Condition, die zu Speicherbeschädigung führt. Und ja: Sie verursacht einen Kernel Panic.

Aber wenn man über die "Ich-hab’s-doch-gesagt" Kommentare der C++ Hardliner hinausschaut, erkennt man etwas Bemerkenswertes: Dieser Bug beweist genau, warum wir auf Rust umgestiegen sind.

Der Bug hinter der ersten RUST-Linux-Kernel-CVE

Schauen wir uns an, was tatsächlich schiefgelaufen ist. Die Schwachstelle ist kein mysteriöser Buffer Overflow, der irgendwo in 50.000 Zeilen Code lauert. Es war ein konkreter Logikfehler in der Datei
drivers/android/binder/node.rs.

Das Problem trat in der Funktion Node::release auf. Der Code versuchte, Einträge aus einer gemeinsam genutzten death_list in eine lokale temporäre Liste zu verschieben.

Die vereinfachte Logik des Fehlers sah so aus:
// Der kritische Fehler in Node::release
// 1. Wir holen uns ein Lock, um auf die Liste zuzugreifen
let inner = self.inner.lock();

// 2. Wir versuchen, Einträge in eine lokale Stack-Liste zu verschieben ...
// ... lassen das Lock aber zu früh los!
drop(inner);

// 3. HIER BEGINNT DIE RACE CONDITION
// Ein anderer Thread greift auf die Liste zu,
// während wir sie verarbeiten
unsafe {
    // Diese Entfernen-Operation ging von exklusivem Zugriff aus
    node_inner.death_list.remove(self);
};
Da das Lock vor Abschluss des unsafe Blocks freigegeben wurde, konnte ein zweiter Thread gleichzeitig die prev und next Pointer der verketteten Liste verändern.

Das Ergebnis? Klassische "Linked List Korruption". Die Pointer verhedderten sich, zeigten auf ungültigen Speicher und der Kernel löste zum Selbstschutz einen Panic aus.

Warum diese erste RUST-Linux-Kernel-CVE tatsächlich gute Nachrichten sind

Wäre dies ein C-Treiber gewesen, hätte diese Race Condition durch implizite Pointer-Modifikationen irgendwo in der Datei entstehen können. Es hätte sich um eine subtile Typverwechslung oder ein Use-After-Free handeln können, versteckt in einem Makro.

Aber in Rust? Wir wussten sofort, wo wir suchen mussten.

Der Bug befand sich innerhalb eines unsafe Blocks.

Der Entwickler musste explizit unsafe schreiben und dem Compiler damit versprechen:
"Vertrau mir, ich habe überprüft, dass kein anderer Thread gerade auf diese Liste zugreift."

Dieses Versprechen war falsch (wegen des zu frühen Lock-Drops), aber der Schadensbereich war klar eingegrenzt.

  • Durchsuchbarkeit: Als der Crash-Report eintraf, mussten die Maintainer nicht den gesamten Treiber auditieren. Ein einfaches grep unsafe reichte.
  • Explizite Absicht: Der Bug war kein syntaktischer Unfall, sondern eine falsche Annahme eines Menschen. Rust hat keinen Speicherfehler übersehen – es hat den Menschen gezwungen, seinen Namen direkt neben den gefährlichen Code zu setzen.
  • Keine aktuellen Hinweise auf RCE: Entscheidend ist, dass dieser Bug einen Denial of Service (Kernel-Panic) verursacht. Zwar kann theoretisch jede Speicherbeschädigung ausgenutzt werden, aber aktuelle Analysen stufen dies als lokalen Crash-Bug ein. Er ist deutlich schwerer zu Remote Code Execution (RCE) zu eskalieren als die üblichen Buffer Overflows in C-Treibern.
Der Linux-Kernel hat zehntausende CVEs. Allein im Jahr 2025 gab es hunderte Memory-Safety-Schwachstellen in den C-Teilen des Kernels – Buffer Overflows, Double Frees, Reads aus uninitialisiertem Speicher.

Rust ist seit Jahren im Kernel.

Anzahl der Rust-CVEs im Linux-Kernel = 1 (diese hier).
Anzahl der C-CVEs = ~unendlich.

Das ist kein Scheitern. Das ist eine Ehrenrunde.

Der Bug wurde gefunden, er wurde behoben, und das System hat genau so funktioniert, wie es entworfen wurde.

Das rust_binder Team hat schlicht die Locking-Logik korrigiert und sichergestellt, dass der unsafe Block seinem Namen auch wirklich gerecht wird.

Also lasst die Kritiker schreien. Während sie noch einen Use-After-Free suchen, der irgendwo in 100 C Header Dateien versteckt ist, wissen wir genau, wo unsere Bugs sind: direkt im unsafe Block.