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

[TrevorBurnham]

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

[bitpshr]

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.