From 09303e99550a7647144642f1467b53898f577431 Mon Sep 17 00:00:00 2001 From: Matt Mastracci Date: Thu, 23 Jan 2025 11:43:03 -0700 Subject: [PATCH] Update RUSTSEC-0000-0000.md Clarification --- crates/openssl-probe/RUSTSEC-0000-0000.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/crates/openssl-probe/RUSTSEC-0000-0000.md b/crates/openssl-probe/RUSTSEC-0000-0000.md index 5453988f0c..7becd8b698 100644 --- a/crates/openssl-probe/RUSTSEC-0000-0000.md +++ b/crates/openssl-probe/RUSTSEC-0000-0000.md @@ -25,8 +25,15 @@ patched = [">= 0.1.6"] `openssl-probe` offers non-`unsafe` methods that call `std::env::set_var`, which may be called in a multithreaded environment, and potentially clash with environment access on other threads. - -When these methods are called while other threads are active and accessing the environment, it +In pure Rust code, concurrent read and write access to the environment is actually safe due to a lock +taken in the platform implementations of the environment accessors (the documentation does not +state this, and it's possible it _could_ change in the future). Libraries using other runtimes +(including Python, those written in pure C and others) do not make use of these internal Rust +environment locks, however, and instead use their own locks, or unprotected raw access to `libc`'s +`getenv`, `setenv`, or even worse, `char** environ`. + +When these methods in `openssl-probe` (or that matter, any other pure Rust code calling `std::env::set_env`) +are called while other threads are active and accessing the environment, it may cause other threads to access dangling environment pointers in the cases where the underlying environment data is moved or resized in response to an additional environment variable being added, or a variable's contents being enlarged.