> no_std for instance does not protect the stack completely. That means that, if you for instance have a simple stack-overflow bug in a Rust program when using no_std, even if the program has absolutely no usage of the unsafe keyword, you can get undefined behavior.

I think you're technically correct, though I also think the picture is a bit more complicated than you paint it. From my understanding, stack overflow protection needs cooperation between (at least) a language, its runtime (if present), and the environment the program is run in. In other words, I'm not sure any language can "protect the stack completely" without knowledge of the environment it's going to be run in, so at least technically speaking I don't think Rust is any different here.

That being said, rustc will insert stack probes even when compiling with no_std, so in environments where stack probes are sufficient to protect against stack overflow/stack clashes no_std is safe with respect to that particular issue.

For example, this short program:

    #![no_std]
    #[inline(never)]
    pub fn f() -> u8 {
        let v: [u8; 16384] = [1; 16384];
        v.iter().sum()
    }

Produces stack probes on e.g., x86_64-unknown-linux-gnu [0]:

    example::f::hb88315ca0b28f303:
        sub     rsp, 4096
        mov     qword ptr [rsp], 0
        sub     rsp, 4096
        mov     qword ptr [rsp], 0
        sub     rsp, 4096
        mov     qword ptr [rsp], 0
        sub     rsp, 4096
        mov     qword ptr [rsp], 0
        push    rax
        lea     rdi, [rsp + 8]
        mov     edx, 16384
        mov     esi, 1
        call    qword ptr [rip + memset@GOTPCREL]
        <further assembly omitted>

[0]: https://rust.godbolt.org/z/rcdvj8j4K