Fix unsynchronized globalRNG use in BN_rand, AddSession, ECDH and X25519

[yosuke-wolfssl]

Problem

globalRNG (src/ssl.c) is a single process-wide WC_RNG with no internal
per-instance locking; its designated lock is globalRNGMutex. The RAND_*
family in src/ssl_crypto.c takes that mutex at all eleven of its call sites.
Four OpenSSL-compat entry points using globalRNG as their primary RNG took no
lock at all, so two threads could interleave DRBG generation on the same V/C
state and produce torn or duplicate output used directly as key material.

Closes f-7543.

Fix

Two remedies, depending on whether the site can cheaply own its RNG:

Site	File	Fix
wolfSSL_BN_rand	src/ssl_bn.c	hold globalRNGMutex across wc_RNG_GenerateBlock
AddSession	src/ssl_sess.c	hold globalRNGMutex across wc_RNG_GenerateBlock, global path only
wolfSSL_ECDH_compute_key	src/pk_ec.c	wolfssl_make_rng() in place of wolfssl_make_global_rng()
wolfSSL_EC25519_shared_key	src/pk.c	same, for the WOLFSSL_CURVE25519_BLINDING RNG

The two lock sites are open-coded in the style already used in those files, so
no new locking convention is introduced.

The two shared-secret paths instead take a per-call RNG via
wolfssl_make_rng() — the helper the rest of pk.c/pk_ec.c already uses —
removing the sharing rather than serializing on it. Holding globalRNGMutex
across the whole shared-secret operation (the first version of this PR) would
have serialized all ECDH process-wide, including keys that carry their own RNG.
Both sites now NULL-check the RNG; wolfSSL_ECDH_compute_key additionally
guards the shared-secret call on !err and clears key->rng before the local
RNG is freed, so no dangling reference is left behind.

Known trade-off

ECDH and X25519 now init and seed a fresh DRBG per call instead of reusing the
global one, which costs performance on those paths. Accepted as an interim
state — still better than the unsynchronized global.

Intentionally not in this PR

• Roughly eighteen further sites reach the global only through
  wolfssl_make_rng()'s fallback, after a local wc_InitRng() has already
  failed. Same defect, far lower reachability.
• A concurrently shared EC_KEY is unsafe independent of the RNG
  (wc_ecc_shared_secret_ex writes private_key->state and dispatches on it).
  That needs per-key locking, which neither wolfSSL nor OpenSSL provides.

Verification

• Builds clean, no new warnings, across opensslall+keygen, opensslextra+all,
  dh+ecc (no OPENSSL_EXTRA), singlethreaded and wpas, plus a
  -DWOLFSSL_CURVE25519_BLINDING build for the Curve25519 path.
• make check: 17/17 on --enable-all, 6/6 on opensslall, 0 failures.
• ThreadSanitizer clean: 32 threads x 150 iterations hammering BN_rand,
  ECDH_compute_key, EC25519_shared_key and RAND_bytes, 0 races.
  Negative control: reverting the BN_rand lock reports races in
  Hash512_DRBG_Generate.

No regression test is added: a threaded test is nondeterministic and there is no
ThreadSanitizer job in CI, so it would add flake without signal.

[Copilot]

Pull request overview

This PR addresses a thread-safety issue where multiple OpenSSL-compat entry points use the process-wide globalRNG without taking its designated lock (globalRNGMutex), risking concurrent DRBG state corruption and unsafe key material generation.

Changes:

• Add globalRNGMutex locking around wc_RNG_GenerateBlock() in wolfSSL_BN_rand() and AddSession().
• Hold globalRNGMutex across EC_KEY->rng mutation and wc_ecc_shared_secret_ex() in wolfSSL_ECDH_compute_key(), including a missing NULL check on wolfssl_make_global_rng().
• Lock globalRNGMutex around Curve25519 blinding usage during wolfSSL_EC25519_shared_key().

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/ssl_sess.c	Locks globalRNGMutex while generating altSessionID via the global RNG.
src/ssl_bn.c	Locks globalRNGMutex around global RNG byte generation in wolfSSL_BN_rand().
src/pk.c	Locks globalRNGMutex during Curve25519 shared-secret generation when blinding is enabled.
src/pk_ec.c	Locks globalRNGMutex across key->rng set/clear and ECDH shared-secret computation, adding a NULL check for the global RNG.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

MemBrowse Memory Report

gcc-arm-cortex-m4-openssl-compat

• FLASH: .text +128 B (+0.0%, 772,972 B / 1,048,576 B, total: 74% used)
  No memory changes detected for:
• gcc-arm-cortex-m0plus
• gcc-arm-cortex-m3
• gcc-arm-cortex-m4
• gcc-arm-cortex-m4-baremetal
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-dtls13
• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-pq
• gcc-arm-cortex-m4-rsa-only
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls12
• gcc-arm-cortex-m4-tls13
• gcc-arm-cortex-m7
• gcc-arm-cortex-m7-pq
• gcc-arm-cortex-m7-tls13
• linuxkm-pie
• linuxkm-standard
• stm32-sim-stm32h753

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #11048

Scan targets checked: wolfssl-bugs, wolfssl-src

Findings: 1
1 finding(s) posted as inline comments (see file-level comments below)

This review was generated automatically by Fenrir. Findings are non-blocking.

[yosuke-wolfssl]

Hello @philljj ,
I reworked on this. Could you please review it again ?

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[dgarske]

Previously (before this PR) ECDH and X25519 shared-secret paths used the global RNG, but now always instantiate and seed a fresh DRBG on every call. This could impact performance for some customers. I think originally this PR grabbed the global and locked it during the entire ECDH/X25519 which caused a different issue. I am not sure what the best solution is and it requires a larger refactor, which @philljj has agreed to take on. For now we'll merge this PR, but it does need some improvement soon (before next release). Its still better than what was in master. Also the PR title and description are wrong, so please correct those. Thanks