[marcobambini]

Ten bugs found by reading through src/, then by a security review of the whole of it. Three write outside their buffers and are reachable from ordinary SQL. Each one was reproduced under AddressSanitizer before being fixed, and each has a regression test.

Release as 1.2.0. No API changed and no index needs rebuilding.

Memory safety

What	Where	Manifests as
Top-k arrays allocated from a size_t byte count through sqlite3_malloc()'s int parameter	vCursorFilterCommon	crash
Buffer sized and write-bounded from two different numbers	vector_from_json	controlled heap write
dimension unbounded, overflowing the size arithmetic downstream	option parsing → turbo_rotation_plan_init	write through NULL

k comes straight from the query, so vector_full_scan('t','v',vec,536870913) asked for 0x100000008 bytes, got 8, and the memset that follows overran them. Not controllable: the value written is zero and the length is fixed, so it is a crash. Both allocations now use sqlite3_malloc64().

vector_from_json took its buffer from sqlite3_malloc((int)alloc), truncating a size_t, while the write bound came from the untruncated alloc. A JSON array with 2^30 commas got an 8-byte buffer and a bound of 1073741825 elements, and the parse loop wrote floats the caller supplies straight past it — the comma count sizes the buffer to the byte, so this is a precise write primitive. Reachable through any vector_as_*() and through the TEXT query-vector argument of both scans. It needs a TEXT value of about a gigabyte, so a host SQLite built with SQLITE_MAX_LENGTH >= 1073741824; the limit that applies is the host's, not the bundled amalgamation's, since this ships as a loadable extension. There is now one capacity in 64 bits, with the allocation and the bound both taken from it.

dimension was only checked for being positive, so it reached INT_MAX. (dim/2)*12 in the TurboQuant rotation plan wraps negative past 357913941, which skips allocating the plan's coordinate arrays — they sit behind if (pair_count > 0), and so does the check that would have caught their absence — and the loop then writes through the resulting null pointer. vector_init with dimension=400000000 plus a TurboQuant vector_quantize crashed the process on an empty table, since the plan is built before any row is read. Dimensions are now bounded at 2^24 where they are parsed, upstream of every one of those computations and of the signed-overflow dim + 7 expressions in the packing helpers. A value above INT_MAX is also rejected rather than wrapped: 4294967300 used to come through as the dimension 4.

Also fixed

• A NULL key in _sqliteai_vector reached strcmp() and crashed the next vector_init(). That table is ordinary and writable, and PRIMARY KEY on a rowid table does not imply NOT NULL.
• A failed vector_quantize() left the context describing an index the rollback had undone, so scans read the chunks at the wrong stride and returned made-up rowids and distances with no error.
• A quant chunk claiming zero vectors was read past the end of its blob: zero is the streaming scans' "load the next chunk" sentinel, so it slipped past the length check beside it, which degenerates to bytes < 0.
• vector_as_*() ignored its optional dimension argument for BLOB input, so a wrong-sized vector was stored and then skipped in silence by every scan.
• max_memory=0 could not be set and a bad value was dropped silently: the parser used a 0 return for failure, and zero is the one value the quantizer reads as "use whatever the index needs".
• The INT8/UINT8 cosine kernels accumulated in 32 bits in the scalar and SSE2 backends. SSE2 now also computes sqrt(a)*sqrt(b) instead of sqrtf(a*b), so all five backends compute the same cosine.

For the reviewer

• Package.swift is deliberately untouched although it still says 1.1.2. Its URL and checksum name a release artifact that does not exist yet, and CI rewrites both after the tag publishes one (see 0c2223a … [auto-update]). Editing the URL by hand would leave Swift consumers on 1.2.0 with 1.1.2's checksum.
• The [Unreleased] changelog lead was removed, not kept. It said the extension was unchanged from 1.1.0 and that a build produced the same binaries — true while that section held only benchmark and README work, false for a release carrying three out-of-bounds writes. changelog.yml publishes this file to the website on the tag, so it is what someone reads to decide whether to upgrade.
• The gigabyte JSON case is covered by a standalone probe, not by the suite. Running it needs that much memory and a different SQLITE_MAX_LENGTH than the project builds with, so putting it in make unittest would cost a gigabyte per CI run. Everything else is in test_malformed_input().
• Coverage limits worth knowing. NEON was exercised natively under ASan. The three x86 backends were only compiled, with their ISAs enabled — there is no x86 host here and Rosetta was unavailable. RVV was read, not run: no RISC-V toolchain. For those four, loop bounds were checked statically only.

Verification

make unittest: 1482 passed, 0 failed (1447 before this branch), identical under ASan + UBSan. No warnings under -Wall -Wextra -Wshadow, on arm64 and on all three x86 backends cross-compiled with their ISAs. The universal dylib builds and loads, reporting 1.2.0. Both exploit probes now return a clean error instead of writing out of bounds.

🤖 Generated with Claude Code