Voor het eerst krijgt bug in Rust-code in Linux-kernel CVE-nummer toegewezen

Voor het eerst is er een bug in de Rust-code in de Linux-kernel gevonden die een CVE-trackingnummer heeft gekregen. Rust zit al sinds 2022 experimenteel in de kernel en wordt gezien als veiliger, met name op geheugengebied.

Greg Kroah-Hartman, een van de hoofdontwikkelaars van de Linux-kernel, schrijft dat er voor het eerst een CVE-nummer is toegekend aan een kwetsbaarheid in een stuk Rust-code in de kernel. Dat betekent niet dat dit de eerste bug is op dat gebied, maar wel de eerste die met zo'n 'Common Vulnerabilities and Exposures'-code te volgen is. De bug wordt getrackt als CVE-2025-68260.

De bug in kwestie kan een crash veroorzaken, zegt Kroah-Hartman, en betreft geen geheugencorruptie. De kwetsbaarheid betreft een race condition in de rust-binderdriver.

Het is de eerste keer dat er een getrackte bug in de Rust-code in de Linux-kernel zit. Dat is redelijk uniek en Kroah-Hartman merkt ook op dat er 159 andere CVE's zijn toegewezen aan kernelcode, maar dat is alleen in C-code. Rust werd in 2022 al experimenteel aan de kernel toegevoegd. De hoofdontwikkelaar van Rust in Linux, Miguel Ojeda, liet eerder deze week al weten dat Rust 'een blijvertje' is voor de kernel. Rust heeft voordelen boven C, waaruit het grootste deel van de kernel nu nog bestaat. Met name op veiligheidsgebied wordt Rust als beter gezien: de kans op geheugenbugs is veel kleiner.

Reacties (26)

[marcelvb]

Veel security bugs zijn geheugen gerelateerd, maar natuurlijk niet alles.

Ik vraag me af of Linus Torvalds ook Rust spreekt eigenlijk.

[Hans1990]

Dit is nog steeds een geheugenbug. Race conditions komen voor wanneer 2 stukken code naar dezelfde geheugen locatie gaan schrijven. Het valt te vergelijken wanneer jij en een collega een document van Dropbox download, ieder afzonderlijk offline die bewerkt, en daarna terug upload. De 1 zal de wijzigingen van de ander overschrijven. Dit valt op te lossen door af te spreken wie de bewerking voor de ander doet (semaphore/mutex).

Nu doet software erg snel z'n taken, dus dat maakt de duur dat een race condition kan voorkomen vaak klein. Maar dat wil niet zeggen dat een aanvaller iets kan proberen te forceren, bijvoorbeeld door kwetsbare code heel vaak uit te voeren (wat op het oog zinloos lijkt).

Als je kijkt in de CVE valt te zien dat het "unsafe" Rust code betreft. Dat is code waarin het mogelijk is om C-style pointers te gebruiken die niet onderhevig zijn aan Rust's borrow checker. Die borrow checker is namelijk een unieke feature van Rust waardoor het zo populair is geworden. En om uit dat artikel het nog even sterker aan te halen: "The borrow checker helps prevent data races"

In andere woorden, Rust is nog steeds veilig, maar unsafe code niet. Helaas kan je met low-level programming er niet altijd omheen om unsafe code te schrijven, bijvoorbeeld om met hardware te praten of om IPC objecten te schrijven. Verder kan low-level C code volatile bevatten, memory barriers, vieze impliciete type casts (in C++ gelukkig meer zichtbaar dankzij "reinterpret_cast") en mogelijk zelfs inline assembly.. details die je in high-level programmeertalen het liefst (zo min mogelijk) niet meer terug ziet.
Dit is ook wat imho C voor zo'n lange tijd zo populair heeft gehouden, omdat voor hardware programmeurs de taal niet in de weg zit. Behalve als het gaat om security dus..

[Reactie gewijzigd door Hans1990 op 18 december 2025 20:41]

[Guru Evi]

Waarom gebruiken ze unsafe code? Als demo voor een “veilige” toekomst is het toch gek dat je “verse” code expliciet met unsafe gebruikt.

In principe zou geen enkele hoofdprogrammeur unsafe mogen toelaten - goed genoeg voor een stukje wegwerpcode maar voor een kernel implementatie of de core libraries zou dat toch niet mogen.

[rjberg]

Unsafe is vaak nodig als interface met C. Dat komt omdat zodra je C code aanroept uit bijvoorbeeld een bibliotheek de compiler niet kan zien wat je doet.

Unsafe code kan op zich nog steeds veilig zijn, maar is niet gegarandeerd door de compiler.

https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html

Verder betekent het ownership systeem van Rust dat veel datastructuren zoals gebruikt in de Linux kernel niet makkelijk in Rust kunnen worden vertaald. Zodra meerdere pointers naar dezelfde data wijzen heb je of een real-time reference counter nodig (overhead), of een manier op compile tijd om een pointer de eigenaar te maken, en die moet langer leven dan de andere pointers.

[bzuidgeest]

Buiten wat @rjberg al zegt. Dingen als unsafe en volatile en wat andere talen het ook noemen komen ook gewoon voor bij en zijn niet te vermijden als je tegen hardware praat. Onder andere via memory mapped io. De waarde die het ene moment er staat kan het andere moment veranderd zijn. Zeker bij status registers en dergelijke.

Er is altijd een plek waar alle code "unsafe" word, zeker in een kernel, zo dicht bij hardware.

[Guru Evi]

Inderdaad, maar wat is dan de toegevoegde waarde van Rust? Een taal die niet tegen de hardware kan praten heeft geen waarde behalve in een academische omgeving. Eenmaal je “unsafe” zegt is niet alleen de code maar ook alles dat op dat geheugen locatie zit mogelijk een probleem.

Blijkbaar was de code specifiek in een linked list, om een object te verwijderen uit een linked list is volstrekt niet unsafe nodig, behalve dan natuurlijk dat de “veilige code” net zo snel als Ruby of Python wordt on runtime checks en global locks toe te passen.

[Reactie gewijzigd door Guru Evi op 18 december 2025 23:41]

[dmantione]

Als jij een Rust-programma op problemen wat betreft bufferoverflows e.d. gaat onderzoeken hoef je je alleen maar op de unsafe-delen te concentreren, terwijl je in C alle code nauwgezet moet bekijken. Dat is een verschil van dag en nacht.

[Argantonis]

Behalve in een academische omgeving? Heb je wel eens van Java en JavaScript gehoord toevallig? Beide kunnen niet direct tegen hardware praten.

[desalniettemin]

En hij gebruikt Fedora.

[TijsZonderH]

M'Linux

[Heedless]

In een video op LTT laatst zei hij Fedora te gebruiken.

[Niema]

Gaat dit over de YouTuber of de bedenker van linux

[pjottum]

Tja, Linus kwam bij Linus langs dus die grap maakten ze zelf.

[downtime]

Ja, ik geloof dat ie Rust kent, maar niet erg goed en laat dat daarom liever aan anderen over.

[Powerblast]

Ik meen dat hij dit vooral aan anderen overal laat. Dacht uit een interview begrepen te hebben dat hij het wel eens tegenkomt in code reviews maar er verder niet actief mee bezig is. Het is en blijft natuurlijk een C mastermind .

[jdvv]

Nee hij spreekt engels

[bhartman]

Fins lijkt me logischer….

[Damic]

Zowel Fins als Engels YouTube: Building the PERFECT Linux PC with Linus Torvalds

[dasiro]

Linus is een Zweedstalige Fin, een linguïstische minderheid van +/- 10% (afhankelijk van de bron), maar het is er wel een officiële taal.

[Kai Nickson]

Por que no los dos

[M. Schaap]

En Zweeds.

Wikipedia: Zweedstalige Finnen

[SPee]

Het is wel grappig en ironisch, omdat Rust juist bedacht is om zulke fouten te voorkomen. En dan zit het er toch in! En nu komt men massaal met de meme die je anders ook zou krijgen:

Herschrijf het in rust, dan heb je dit probleem niet.

Een uitleg over de bug.

[Immutable]

Ach tis ook beetje de reden net zoals alles wat polariseert. Dat nu elk stukje code in Rust in de kernel onder een 100x vergrootglas ligt. Omdat er zoveel tegenstanders zijn vooral mensen die techniek en politiek graag mengen.

Natuurlijk kan Rust code nog steeds bugs en problemen bevatten. De kans erop is alleen een stuk kleiner. Maar niet 0%. En niemand beweert dat behalve mensen die er tegen zijn beweren dat de andere kant het beweert. Het zeg maar in de mond legt.

[Reactie gewijzigd door Immutable op 19 december 2025 02:07]

[Argantonis]

De kans op specifieke gevaarlijke bugs in Rust is kleiner. De kans op bugs in het algemeen lijkt me niet veel kleiner. Misschien enigszins ten opzichte van C/in de context van Systems programming maar ik schat dat dat verschil niet gigantisch zal zijn. Ten opzichte van andere soorten projecten waarin performance van een regel code al minder uitmaakt ten opzichte van I/O zoals grote online backends die al geschreven zijn in memory-safe talen zal Rust niet opeens minder bugs tot gevolg hebben.

[simnet]

Iedereen roept maar rust is beter, rust is veiliger. Wat ik wel eens zou willen weten is hoeveel CVE's er toegekend zijn aan C code die de laatste 3 jaar geschreven is.

Tooling is er namelijk ook enorm op vooruit gegaan. Fuzzing, chaos engineering zijn allemaal gewoon goed geworden. Linters en static checkers vangen al enorm veel fouten af voor ze gecommit worden.

Ik zou alleen niet weten waar je zoiets zou kunnen opzoeken.

[gimbal]

Het lijkt ook een vrij grove stap om maar een hele andere taal te gaan gebruiken. Ik zie meer heil in de ontwikkeling van FIL-C om bestaande C code beter veilig te kunnen maken zodat je wel kunt blijven leunen op de decennia aan ervaring van C programmeurs om fouten in de code te kunnen herkennen.

Puntje bij paaltje is Rust alleen rust-gevend als alle code Rust is. Rust introduceren in een zee van C... dapper hoor. We moeten maar gaan zien hoe vaak Low Level volgend jaar iets mag gaan uitleggen wat er 100% veilig uitziet maar exact het tegengestelde blijkt te zijn.