У нас тут тема про то, что очередной погромист, любитель дыряшек, выдавил из себя такой код, что RCE в ядре была почти год.
И спасибо гуглу и его программистам, что они делают опенсорс лучше, а то тыщящи глаз как-то ничига не видят

Ну давай посмотрим, че там:
[CODE]
pub fn segfault() -> ! {
       let null = crate::null_mut::<u8>();
        *null = 42;
[/CODE]
Смотрим, че эт за самописный null_mute:
[CODE]
/// Equivalent to ['std::ptr::null()'], but returns a null reference instead.
pub fn null<'a, T: 'static>() -> &'a T {
        crate::transmute(0usize)
}
[/CODE]
далее оно уходит в велосипедно-обфусцированный transmute, в общем раз "equivalent", то заменяем на оригинал:
[CODE]
+++ b/src/segfault.rs
@@ -7,7 +7,7 @@
///
/// See ['crate::transmute()']
pub fn segfault() -> ! {
-       let null = crate::null_mut::<u8>();
+       let null = std::ptr::null_mut::<u8>();
        *null = 42;
[/CODE]
и вуаля:
[CODE]
cargo build
   Compiling cve-rs v0.6.0 (/tmp-build/seg/cve-rs)
error[E0133]: dereference of raw pointer is unsafe and requires unsafe function or block
  --> src/segfault.rs:11:2
   |
11 |     *null = 42;
   |     ^^^^^^^^^^ dereference of raw pointer
   |
   = note: raw pointers may be null, dangling or unaligned; they can violate aliasing rules and cause data races: all of these are undefined behavior

For more information about this error, try 'rustc --explain E0133'.
error: could not compile 'cve-rs' (lib) due to previous error
[/CODE]
В общем, опеннетный Военов Супротив Раста опять развели, как кроликов ...

Главное, повторять почаще.

Если для случайного выстрела в ногу, как в сишечке, нужен консилиум из нескольких программистов и несколько дней упорных попыток выйти за границы буфера - то это эпик фейл растохейтров.

ну типа, да, нынешняя реализация трейтов в rustc - чистый ужас, и ее нужно переделывать, это уже и так известно достаточно давно
но это же не проблема в спеке, спек сам уже формально доказан

это как ткнуть в баг в gcc или clang и сказать, что это весь си неправильный

Но почему-то никто этого не сделал перед тем, как принять код в ядро. Ни комитет, который принимает патчи, сам Линус, ни мейнтейнеры, ничего не сделали, чтобы предотвратить это. Либо делали, но намерено скрывали, чтобы продать информацию троянописателям.

"should work on any standard-compliant platform. There has been recent notice that some compilers violate the standard by not always respecting the volatile qualifier."
==>
"calling functions and accessing volatile-qualified objects can still be optimized out (while maintaining strict conformance to the standard)"

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1381.pdf

В частном хватает std::shared_ptr<>.

> В специальном случае программист может следить за тем, чтобы
> адреса такого рода хранились бы каждый в единственном экземпляре, что делает
> поиск ненужным.

Это делает std::unique_ptr<>.

А Rust что делает? unique_ptr выполняет на этапе компиляции, а в остальных случаях просто бьёт по руками и не позволяет написать код? Или там свой std::shared_ptr<> для неопределённого на этапе трансляции количества указателей?

Нет, не надо быть зассыхой и надо работать из-под учётки root, тогда все уязвимости в получении прав root'а теряют смысл   ;-)