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

keystore: fix memory leak for LRU cache

Public commit record

What the developer wrote

Authored by SomberNight

68/100 · Adequate
keystore: fix memory leak for LRU cache

Using `@functools.lru_cache` on an instance method behaves in interesting ways.
The cache kept a ref around for `self`, so in effect we were never GC-ing keystore objects. Effectively there was a single global cache for derive_pubkey, with keys `(keystore, for_change, n)`.

This PR now changes the caching to be per-keystore:
each ks has a cache, keyed `(for_change, n)`.
GC-ing individual keystores should now be possible, which should result in cleaning up just their own cache.

This also enables the corresponding previously silence flake8-bugbear check for `@functools.lru_cache`. (note that the check can selectively be disabled by adding a comment on the relevant line: `# noqa: B019`)
✓ 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 memory leak in Electrum's keystore code. Previously, a caching decorator on key-derivation methods kept a permanent reference to each keystore object, preventing them from being cleaned up by normal garbage collection. The change moves the cache to live inside each keystore object, so when a keystore is no longer needed, its cache is discarded too. This is a reliability/performance bug fix rather than an active security vulnerability, though unbounded memory growth can degrade or destabilize long-running processes.

Recommended action

Treat as a routine bug fix / hardening patch. No immediate security response is indicated, but users running long-lived Electrum processes may benefit from the reduced memory growth. Reviewers should verify the new `LRUCache` has appropriate size limits and thread-safety for Electrum's usage.

Security signals we found

01

Memory leak / unbounded cache growth

02

Strong reference retention via functools.lru_cache on instance method

03

Potential denial-of-service via memory exhaustion in long-running wallet operations

04

No evidence of confidentiality or integrity compromise

Risk score

Why this scored 25/100

Our methodology →
Potential impact 4/30
Exploitability 2/25
Stealth signal 3/15
Affected reach 5/15
Confidence 7/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.