Ezt majdnem beírtam én is.
Aztán majdnem meg +1-eztem.
Aztán elgondolkodtam rajta :)
A rust (amíg safe-en belül maradsz) a memória-biztosságot garantálja, versenyhelyzetek esetén is. Ezen felül ad bizonyos garanciát a "data race"-ek (konkurens írás-olvasás vagy írás-írás) ellen. Ez nem 100%-os, mutable referenciákkal kijátszható. Nyilván általános, külső-eredetű események közötti versenyhelyzetekre a rust sem garantál semmit.
Itt nagyon az implementációs részleteken múlik, hogy ezt a hibát a rust alapból kivédte-e volna vagy sem. A leírás alapján (https://www.openwall.com/lists/oss-security/2024/07/01/3) nekem az jött le, hogy a glibc-ben levő függvények által, belül hívott malloc()-ok között kellett a versenyhelyzetet előidézni, hogy a támadás sikerüljön. Ha ezeket teljesen rust-ban teljesen safe függvényekkel oldanák meg, akkor igen, védett volna (a memória-allokáció teljesen versenyhelyzet-biztos). De mondjuk egy syslog() vagy hasonló hívásnál valahol kell lennie legbelül egy unsafe résznek, mert a külvilággal kommunikál. Ha ezt a részt meg lehet oldani hogy memóriát ne allokáljon akkor még mindig jók vagyunk.
Én most arra hajlok, hogy ez ellen konkrétan védett volna a rust. Ez nyilván nem minden versenyhelyzetből adódó biztonsági hibára igaz.