On Mon, Sep 8, 2025 at 12:11 AM Markus Koschany <[email protected]> wrote: > I believe the issue was introduced with the following upstream commit > https://github.com/sqlite/sqlite/commit/d1fbaa071bac376206cc009ecdce95b13e131b62 This might as well be the introducing commit: https://github.com/sqlite/sqlite/commit/94c521295aa898eb07dcfc4cf4ccdeb04ff7d735 As this is the step the computation of the apTomb / pNew size for sqlite3Fts5MallocZero() changed. It was 'sizeof(Fts5Data)*nTomb' before and changed to 'nTomb * sizeof(Fts5Data*) + sizeof(Fts5TombstoneArray)'. Either way, the FTS5 extension seems to be (or it was) problematic. See some of its commits: - NULL pointer dereference: https://github.com/sqlite/sqlite/commit/1ddcf7dd95968a470c37437fac8a72cb215a2167 - usan signed integer overflow: https://github.com/sqlite/sqlite/commit/0810150532cf54f5b6945e9a650468f13298373c - integer overflow during integrity_check: https://github.com/sqlite/sqlite/commit/c1805ab222214ddce9779691543117868291c7a0 - OOM case: https://github.com/sqlite/sqlite/commit/5e5831a760e066318f0a63e0665dae7aa39afe6c - crash if shadow tables are modified or removed: https://github.com/sqlite/sqlite/commit/ad460db7eb21cbcdd4f509653f86acbcf43029dc - OOM from sqlite3_blob_close(): https://github.com/sqlite/sqlite/commit/b80d01a18237eceabbe86d77b7f43acc1815c73f - use after free: https://github.com/sqlite/sqlite/commit/9e639d249062d99788b6b10e022d79acc066c78a - another use after free: https://github.com/sqlite/sqlite/commit/c2b446f16a0902a015a046489db6d14ceb8b1bd6 ...
I don't know how these should be handled. Maybe a full backport of SQLite3? There might be other issues around. Still looking for advice from the security team. Cheers, Laszlo/GCS
