sqlite: reject connection access from authorizer callbacks

[TrevorBurnham]

Per sqlite3_set_authorizer(), an authorizer callback must not modify the connection that invoked it, and sqlite3_prepare_v2() and sqlite3_step() both count. node:sqlite allowed the callback to call prepare(), exec(), the statement execution methods, and other connection-mutating APIs on the same DatabaseSync.

Authorizer reentrancy. Track authorizer depth on DatabaseSync with an RAII guard around the callback and throw ERR_INVALID_STATE from the affected entry points while it is on the stack. Depth is per-connection, so a different DatabaseSync stays usable.

Guarded: prepare, exec, serialize, setAuthorizer, createSession, applyChangeset, createTagStore, function, aggregate, enableLoadExtension, enableDefensive, loadExtension, the limits setter; stmt.run/get/all/iterate; iter.next/return; sqlTagStore.run/get/all/iterate/clear; session.changeset/patchset. db.close() and db.deserialize() keep their existing callback-depth messages.

The guard covers every authorizer invocation, not just those from an explicit prepare(): SQLite may re-prepare during sqlite3_step() after a schema change, and serialize() and the session changeset methods prepare internally. Reentry through changeset() never terminated — it recursed until the process died, uncatchable from JavaScript.

Statement reentry. Covering the re-prepare path surfaced a memory-safety bug rather than a contract violation: a statement that is currently being stepped cannot be reentered. Finalizing it frees the virtual machine sqlite3_step() is running, and re-running it through run(), get(), all(), iterate(), or the equivalent tag store methods resets that virtual machine mid-execution. Both segfault, and neither is authorizer-specific — a user-defined function reaches them:

const { DatabaseSync } = require('node:sqlite');
const db = new DatabaseSync(':memory:');
db.exec('CREATE TABLE t (x INTEGER, txt TEXT)');
for (let i = 0; i < 200; i++) db.exec(`INSERT INTO t VALUES (${i}, '${'z'.repeat(500)}${i}')`);
let stmt;
db.function('boom', (x) => { try { stmt.run(); } catch {} return 1; });
stmt = db.prepare('SELECT boom(x), txt FROM t');
for (const row of stmt.iterate()) { void row.txt; }  // SIGSEGV before this patch

Swapping stmt.run() for stmt.close() crashes the same way, as does re-entering the same cached tagged literal on a tag store. A single reentrant call on a small result set often returns cleanly, so the crash needs a row payload large enough to force a page fault, or nesting.

Gating on "any callback is running" would forbid a UDF from preparing, running, and finalizing its own helper statement, which is safe. Instead, track the statements currently being stepped and reject reentry into only those, with statement is already being executed. Tracking is a stack, so a UDF may reenter an inner statement it stepped but not the outer one, and it spans the paired sqlite3_reset() calls, which can run JavaScript through an aggregate's xFinal. statement[Symbol.dispose]() returns early when already finalized, so disposal stays idempotent and can't demote a using scope's real exception to a SuppressedError.

Notes for reviewers

• node:sqlite is Stability 1.2, so this changes behavior directly and throws immediately, per the discussion in the issue.
• backup() and Session.close() are reachable from an authorizer and left unguarded: sqlite3_backup_step takes the source connection's mutex and blocks until the in-progress step finishes (120 stress iterations at rate: 1, no corruption), and deleting a session doesn't touch the VM under step. Happy to add them.
• sqlTagStore.clear() only clears a JS-side cache; guarded because the issue lists it, easy to drop.
• iterator.next() on a drained iterator throws inside an authorizer instead of returning { done: true }.

Verification. 20 sqlite test files plus test-webstorage pass (31 tests in test-sqlite-authz.js, 32 in test-sqlite-udf-close.js). make format-cpp reports no changes; lint-cpp, lint-md, eslint, checkimports.py, and cpplint.py are clean. Mutation-tested: removing the eight statement-reentry guards while keeping close()/dispose() fails the new tests, and neutering the stepping gate entirely crashes both new test files with signal 11.

Fixes: #63207

[nodejs-github-bot]

Review requested:

• @nodejs/sqlite