AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 68 Bitcoin

internal: avoid potential info leaks via sse/avx registers

Public commit record

What the developer wrote

Authored by Jon Griffiths

73/100 · Adequate
internal: avoid potential info leaks via sse/avx registers

In particular when built as a shared library, calls through the PLT
spill these registers onto the stack.

Thanks to @pythcoiner <pythcoiner@proton.me> for identifying the
leak cause and suggesting a fix.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a potential information leak in a cryptocurrency wallet library. When the library is built as a shared library on x86/x86_64 systems, optimized memory-copy functions can leave secret data (private keys, seed phrases, chain codes) inside special CPU registers (SSE/AVX). If the program then makes a call through the dynamic linker before those registers are reused, the CPU spills the register contents onto the stack, where they may remain uncleared. The patch replaces many ordinary memory copies with a simple, unoptimized byte-by-byte copy function for sensitive data, preventing the data from being left in those registers. The commit message explicitly calls this an 'info leak' and thanks an external contributor for finding the cause and suggesting the fix.

Recommended action

Users building libwally-core as a shared library on x86/x86_64 Linux should upgrade to a revision containing this commit. Developers should ensure wally_memcpy is used for any new code paths that copy secret material, and should run the test_clear regression test in shared-library builds to confirm the leak is mitigated. Consider also auditing other cryptographic libraries in the same process for similar register-spill issues.

Security signals we found

01

Information disclosure via CPU register spill to stack

02

Shared-library/PLT-specific side channel

03

Use of SSE/AVX registers by optimized libc memcpy

04

Replacement of memcpy with unoptimized wally_memcpy for secret data

05

Hardening of BIP32 private key and chain code handling

06

Hardening of BIP39 mnemonic/seed handling

07

Hardening of WIF private key import/export

08

Updated test_clear regression test to detect stack leaks

Risk score

Why this scored 68/100

Our methodology →
Potential impact 22/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 12/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.