sqlite: two reentrancy guard gaps let a callback free the object SQLite is still using

Version

main (03fb384)

Platform

Darwin fcb214bb6048 25.6.0 Darwin Kernel Version 25.6.0: Fri Jul 31 19:19:08 PDT 2026; root:xnu-12377.161.14~5/RELEASE_ARM64_T6050 arm64

Subsystem

sqlite

What steps will reproduce the bug?

Free memory that SQLite is still using from a callback:

import { DatabaseSync, constants } from 'node:sqlite';

const db = new DatabaseSync(':memory:');
db.exec('CREATE TABLE t(a PRIMARY KEY)');
const session = db.createSession();

let once = true;
db.setAuthorizer((action, p1) => {
  if (action === constants.SQLITE_PRAGMA && p1 === 'table_xinfo' && once) {
    once = false;
    session.close();
  }
  return constants.SQLITE_OK;
});

db.exec('INSERT INTO t VALUES (1)');

How often does it reproduce? Is there a required condition?

The fault always occurs, but it's not always visible under the default allocator. Run with
MallocScribble=1 MallocPreScribble=1 MallocNanoZone=0 on macOS and you get exit 139 deterministically; without it, the script can exit 0.

What is the expected behavior? Why is that the expected behavior?

statement.close() should throw ERR_INVALID_STATE. Per doc/api/sqlite.md:

An ERR_INVALID_STATE error is thrown if this statement is currently executing, which happens
when the method is called from a callback that the statement itself triggered, such as a
user-defined function, an aggregate function, or a 'sqlite.db.query' subscriber.

What do you see instead?

A use-after-free. Under MallocScribble, lldb stops in sqlite3VdbeMemSetNull(pMem=0xaaaaaaaaaaaaaaaa) with EXC_BAD_ACCESS.

Additional information

No response

Confirming this reproduces on macOS arm64 against main (v27.0.0-pre). One thing worth adding: it is more deterministic than the report suggests. I get exit 139 on 8 of 8 runs, and the default allocator crashes just as reliably as with MallocScribble=1 MallocPreScribble=1 MallocNanoZone=0, so the allocator flags were not needed here to see it.

DatabaseSync::Exec() and the changeset-apply path already hold a BaseObjectPtr<DatabaseSync> across the SQLite call for this same hazard, but that only keeps GC from collecting the database. An explicit session.close() inside the callback calls sqlite3session_delete() while SQLite is still using the session, which that guard does not cover.

sqlite: reject closing a session from a callback

Navigation Menu

Repository navigation

sqlite: two reentrancy guard gaps let a callback free the object SQLite is still using #65428

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

sqlite: two reentrancy guard gaps let a callback free the object SQLite is still using #65428

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Activity

bitpshr commented on Aug 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions