> > a concurrent execution race condition within the assign_headers() function when handling shared resources [...] can corrupt heap memory to achieve arbitrary code execution (RCE)

To my understanding, in safe Rust to share between threads the compiler will require something like Arc<Mutex<...>> - which prevents unsynchronized access or freeing while another thread is still using it.

One of the core claims of the language is data race safety because in safe rust, no memory location can be written by two or more owners at the same time. (see https://doc.rust-lang.org/nomicon/races.html for a more detailed discussion) Consequently, the kind of memory corruptions that this vulnerability seems to exploit are not possible in safe rust. Now, we don't know if a hypothetical rust-based apache implementation would have reached for unsafe in this context or done any other wild thing, but it's fair to assume that the likelihood of an exploitable RCE through memory corruption trends towards zero in programs written in Rust.

The details I've seen are too sparse to say with certainty, but it seems like the issue is concurrent access to the same value through a pointer.

In particular it's `req` in the function with this signature:

    static void assign_headers(request_rec *r, const h2_request *req,
                               int no_body, int is_connect)

                - apr_table_setn(req->headers, "Content-Length", "0");
                + apr_table_setn(r->headers_in, "Content-Length", "0");

In Rust this would've been `req: &h2_request` and the accidental write wouldn't have been possible (barring interior mutability). Even with interior mutability there is no thread interleaving during the write, which happens through a `&mut h2_request` probably obtained through a lock.

They've published an article last month on the Nginx vulnerabilities in light of their Rust implementation.

https://xin.dev/blog/multiple-nginx-vulnerabilities/