SQLite 3.54.1 fixes opcode allocation on 32-bit builds

A small optimization in SQLite's statement preparation code miscounted the usable tail of an allocation on some 32-bit builds. SQLite 3.54.1, released on 16 October 2026, fixes the resulting possible heap-buffer overflow. The release notes explicitly exclude 64-bit builds from this particular problem. The interesting detail is the accounting for alignment, because the allocation did not need to fail for the code to write beyond it.

SQLite has been part of my work for twenty-five years, and this site runs on it. Its deployment model remains one of the reasons I like it so much. This fix concerns the C implementation beneath that model. The database file can be ordinary, the SQL can be ordinary, and a build-specific memory calculation can still invalidate an assumption about where a write is safe.

Alignment consumed space the calculation still counted

The original report traces the error to sqlite3VdbeMakeReady(). The code rounded the start of unused opcode memory upward for alignment, but its calculation of available bytes did not subtract that rounding. On the reported 32-bit layout, an opcode occupied twenty bytes. Certain combinations of allocated and used opcodes therefore described a region extending four bytes beyond the real allocation.

For instance, the report calculates an allocation of 1,020 bytes and an aligned starting offset of 984 bytes. Calling the remaining space forty bytes makes its end 1,024. The allocation itself ends at 1,020. The arithmetic shows why rounding the starting address and counting whole unused objects independently can disagree about the same buffer.

The correction in check-in 6ebd1e69486cabc6 restores tracking of the allocation's byte size. After calculating the aligned starting offset, it subtracts that offset from the allocation size and rounds the remainder down. Both ends of the usable region now refer to the same allocation boundary. The commit describes this as backing out the minor optimization.

This is a bounds error in reuse of an existing allocation. A generic check that an allocator returned a non-null pointer would not establish that the subregion derived from it is valid. The critical invariant concerns the sum of the chosen starting offset and the usable length, which must remain within the actual allocation.

Statement preparation owns real memory

SQLite's prepare interfaces compile SQL text into a prepared statement object. Execution happens through that object afterward. The separation helps explain why memory safety in preparation matters even before an application consumes any query results.

The report uses a small in-memory database and ordinary DDL. It does not require a specially corrupted database file. That makes the affected build configuration central to the diagnosis, since the statement text alone does not explain why another executable may behave differently.

The same SQL can still be useful as a compact integration fixture. Its expected logical behavior is to create the table and add a column successfully.

CREATE TABLE t(a);
ALTER TABLE t ADD COLUMN b INTEGER;

A memory-safety check around that fixture asks a different question from a schema assertion. The schema assertion checks the resulting database definition. The memory check examines whether the implementation stayed inside its allocations while producing that definition. Passing one does not imply passing the other.

A build target is more precise than a machine label

The release scopes this overflow to 32-bit builds. The relevant property belongs to the executable and library being used. A machine's ability to run 64-bit software does not identify the ABI of every process it launches, and an inventory based only on the host model can overlook a separately built utility.

SQLite provides runtime version identification for determining which library is loaded. Those interfaces report version and source information associated with the library, independently of the compilation headers. Build metadata supplies the additional target information needed to interpret this particular advisory.

An embedded deployment can have several SQLite consumers with independent release schedules. A language binding and an administrative utility may bundle different engines. The useful unit of an upgrade record is therefore the actual executable with its loaded library and target configuration.

I value SQLite's directness, but that directness does not remove the application's responsibility for packaging. A source dependency update has practical effect only when it reaches the binaries that open the database. This patch makes that distinction especially concrete because one target class is affected and another is expressly excluded.

Allocator instrumentation exposes a different failure class

SQLite's memory-allocation documentation describes a debugging allocator with sentinel values around allocations. It also describes initialization patterns that help expose uninitialized reads and use after free. These checks examine misuse of successfully allocated memory, which differs from testing behavior when allocation returns an error.

That distinction is useful beyond this patch. An application can handle out-of-memory errors correctly while still miscalculating a region inside a successful allocation. A test configuration designed to fail allocations exercises one set of branches. Instrumentation around allocation boundaries examines another property.

The debugging allocator has a cost, and SQLite documents it as a testing tool with substantial overhead. Production allocation behavior and diagnostic allocation behavior serve different purposes. Retaining a targeted regression under the diagnostic configuration preserves evidence about the memory boundary without making that instrumentation a requirement for every production database operation.

The 3.54.1 maintenance history also includes query-result corrections and CLI fixes. The architecture-specific overflow is the release's most prominent repair, but its absence on a 64-bit build does not imply that every other change is irrelevant there. In particular, query correctness remains a separate reason to evaluate the patch against the application's expected results.

For affected 32-bit deployments, 3.54.1 supplies the upstream repair without requiring an application to redesign its schema or avoid ALTER TABLE. The allocation calculation changes inside the engine. The application can retain the SQL behavior it intended while updating the implementation that prepares it.