Sensitive key material left on kernel stack across multiple paths
Summary
Poly1305 one-time key poly_key[32] generated in _chacha20poly1305_init never zeroized before function returns. ChaCha context ctx (whose chacha.input[4..11] holds full 256-bit master/session key schedule) never zeroized on error paths of chacha20poly1305_encrypt_mbuf/_decrypt_mbuf. _chacha20poly1305_mbuf returns EINVAL at lines 317 and 338 without touching ctx so caller returns with full key schedule and poly state still on stack frame. XChaCha wrappers DO zero derived_key but same hygiene not applied to poly_key. Requires separate stack-info-leak primitive. For WireGuard caller exposes session key decrypting/injecting all traffic for that keypair. [VERIFIED pass2: NOT REPRODUCED AT RUNTIME - missing wipes are line-accurate but success-path stack recycling hides residency and the mbuf error paths gate on m_copydata KKASSERTs first (two panics captured proving the gate); explicit_bzero fix applied and build-validated; hardening stands]
Discussion (0)
PoC verification
Evidence pack
findings/poc/DF-2363 · 7 files| File | Type | Description | Size | |
|---|---|---|---|---|
| env.txt | — | 412 B | view raw | |
| fix.diff | — | 1.3 KB | view raw | |
| rig | — | 4.0 KB | ↓ download | |
| run_fixed_kernel.log | — | 2.8 KB | view raw | |
| run_kernel_baseline.log | — | 172 B | view raw | |
| verdict.json | — | 2.3 KB | view raw | |
| fix.diff | — | 1.3 KB | view raw |
Fix verification
not_testableConfirmed kernel references
Detail
Evidence (decisive lines)
run_fixed_kernel.log (aead/xchacha scans: absent; initframe scan found only the rigs own expected-value copy - documented artifact), panic captures for both mbuf-consistency attempts, fix.diff
PoC changes
mbuf error-path scenario went through three chain shapes; each hit the mbuf subsystems own bounds assert before the chachapoly EINVAL - recorded as an observation about the error paths testability
Verified recommended fix
explicit_bzero poly_key after use and the ctx on the EINVAL error paths
Verdict
The missing wipes are line-accurate facts: poly_key[32] (chachapoly.c:52) is bzeroed only before generation and never after use, and the ctx key schedule is only wiped in _final (:192/:196) - the EINVAL returns at :317/:338 leave it on the stack. But the runtime could not demonstrate residency above the rig noise floor: on the plain-encrypt success path the sibling frames of _update/_final recycle the exact stack region before the caller can scan it (measured: key-bytes and poly_key both absent after return), and the mbuf error path cannot be entered in isolation because any chain inconsistent with m_pkthdr.len trips the m_copydata/m_getptr KKASSERT inside _chacha20poly1305_mbuf first (two distinct panic captures in the pack). The explicit_bzero fix is still correct defense-in-depth and is validated by build; classifying not_reproduced because no observable leak was demonstrated on this guest.
No comments yet.