It does have invulnerability to data races. However, that guarantee applies only to data types and code in Rust.

The dangerous interaction between signals and other functions is outside of what Rust can help with.

There are several crates available which implement the dangerous parts of signal handling safely for you.

There are, but safety of their implementation is not checked by the language.

Rust doesn't have an effect system nor a similar facility to flag what code is not signal-handler-safe. A Rust implementation could just as likely call something incompatible.

Rust has many useful guarantees, and is a significant improvement over C in most cases, but let's be precise about what Rust can and can't do.

> Rust doesn't have an effect system nor a similar facility to flag what code is not signal-handler-safe.

My understanding is that a sound implementation of signal handling in Rust will require the signal handler to be Send, requiring it only has access to shared data that is Sync (safe to share between threads). I guess thread-safe does not nessecarily imply signal-safe, though.

And of course you could still call to a signal-unsafe C function but that requires an unsafe block, explicitly acknowledging that Rust's guarentees do not apply.

Signal handlers are not threads. Rust doesn't have anything that expresses the special extremely restrictive requirements of signal handlers.

A safe-Rust thread-safe Send+Sync function is allowed to call `format!()`, or `Box::new`, or drop a `Vec`, all of which will directly cause the exact same vulnerability as in SSH.

There is nothing in Rust that can say "you can't drop a Vec", and there are no tools that will let you find out whether any function you call may do it. Rust can't even statically prove that panics won't happen. Rust's panic implementation performs heap allocations, so any Rust construct that can panic is super unsafe in signal handlers.

The crates that I have looked at work by installing their own minimal signal handler which then puts a message into a channel, or otherwise delivers the message that the signal was fired to your code in a safe way.

Of course, you are still trusting that the implementation is sound.

This bug seems to be exploitable due to a memory corruption triggered by the race condition, it's the memory corruption that rust would protect from.

No. You can't protect against arbitrary "memory corruption" without also covering race condition.

While this is a common misconception, I'm already tired of enthusiastic "safu language fans" trying to explain what bound checks mean to me so apologizes for being mean.

But no, in 2024 you should focus on temporal memory safety which is much harder to eliminate compared to "just add boundz CHK everYwHErE!!!@".