# 16 instances where return value of OpenSSL i2d_RSAPublicKey is discarded -- might lead to use of uninitialized memory

Tor ignores i2d_RSAPublicKey return value in 16 call sites, leaving stack buffers uninitialized when memory allocation fails, leaking stale memory into digests.

- Payout: hidden
- Severity: low
- Program: Tor
- Found by: guido
- Disclosed: 2017-11-26
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/142773
- Library page: https://bugbountylibrary.com/r/h1%3A142773
- Tags: area:oss domain:oss impact:data-leak kind:bounty platform:hackerone sev:low tech:linux technique:source-review vuln:info-disclosure vuln:memory-corruption

**Target:** Tor daemon crypto/digest functions (tortls.c, router.c, dirvote.c, rendcommon.c)
**Root cause:** Callers of crypto_pk_get_digest/get_fingerprint/rend_get_service_id don't check the return value; when i2d_RSAPublicKey fails (OOM), the output buffer is never written and retains uninitialized stack contents.
**Steps:**
1. Trigger memory exhaustion (e.g. `ulimit -Sv 500000` then exhaust heap) so i2d_RSAPublicKey's internal allocation fails.
2. Call `crypto_pk_get_digest(pk, digest)` with an uninitialized stack buffer.
3. Observe return -1 but `digest` still holds its prior uninitialized contents, which then flows into fingerprints/service IDs.
**How found:** Code review of every i2d_RSAPublicKey caller, noting which output buffers were tor_malloc_zero'd vs left as uninitialized stack buffers, then confirming with a PoC under ulimit.
**Insight:** When auditing crypto wrappers, enumerate every caller of a function that can fail on allocation and check whether the output buffer is zero-initialized or stack-allocated; OOM is an attacker-reachable failure path via memory leaks.