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

wallet: store m_additional_flags in SQLiteDatabase to fix reopen path

Public commit record

What the developer wrote

Authored by Pablo Martin

73/100 · Adequate
wallet: store m_additional_flags in SQLiteDatabase to fix reopen path

SQLiteDatabase::Open() (the public override) always reopens the database
with no additional flags. If SQLiteBatch::Close() triggers the
force_conn_refresh path (TxnAbort failed), it calls Open() which drops
the original additional_flags, causing in-memory databases to be reopened
as on-disk instead.

Store additional_flags as a member and use it in Open() so the reconnect
preserves the original flags. For in-memory databases, connection recovery
makes no sense as all data would be lost; both the force_conn_refresh path
and the public Open() now throw instead.

Co-authored-by: Sjors Provoost <sjors@sprovoost.nl>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This patch fixes a bug in Bitcoin Core's SQLite wallet code where an in-memory test wallet could accidentally be reopened as a real on-disk database, or be lost entirely during error recovery. The fix stores the original database flags so reopening preserves them, and explicitly throws an error instead of trying to recover a connection to an in-memory database (which would lose all data). It appears to be a correctness/reliability fix rather than an active security vulnerability in normal production use.

Recommended action

Treat as a routine bugfix/correctness patch. Reviewers should confirm that in-memory wallet tests still behave correctly and that no production path relies on reopening in-memory databases. No urgent security response is indicated by the commit materials alone.

Security signals we found

01

Data-integrity bug in wallet database reopen path

02

In-memory database could be silently reopened with different flags

03

Connection recovery path could discard wallet state for in-memory DBs

04

No explicit security framing in commit message or diff

Risk score

Why this scored 31/100

Our methodology →
Potential impact 8/30
Exploitability 3/25
Stealth signal 4/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.