Hi Laszlo, On Mon, Sep 08, 2025 at 05:44:25PM +0200, László Böszörményi (GCS) wrote: > 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.
There is some progress on the question, cf. as well https://github.com/google/security-research/issues/242 Regards, Salvatore
