https://sqlite.org/cves.html lists CVE-2025-6965 as fixed in 3.50.2
(released 2025-06-28) with the description of "An attacker who can inject
arbitrary SQL statements into an application might be able to cause an
integer overflow resulting in a read off the end of an array." and points
to https://sqlite.org/src/info/5508b56fd24016c1 for the fix.
More recently, Google Security Research released their report at
https://github.com/google/security-research/security/advisories/GHSA-qj7j-3jp8-8ccv
which states:
Summary
-------
An integer truncation vulnerability exists in SQLite's handling of
aggregate queries with a very large number of distinct column
references. When the number of columns processed in an aggregate
context exceeds 32,767, the index used to track these columns is
truncated from a 32-bit integer to a signed 16-bit integer, resulting
in a negative value.
Severity
--------
High - The exploitation of this vulnerability can lead to remote code
execution and potential for significant damage.
Vulnerability Details
---------------------
An integer truncation vulnerability exists in SQLite's handling of
aggregate queries with a very large number of distinct column
references. When the number of columns processed in an aggregate
context exceeds 32,767, the index used to track these columns is
truncated from a 32-bit integer to a signed 16-bit integer, resulting
in a negative value [1].
In debug builds, this invalid value leads to assertion failures
[2][4]. In non-debug builds, the corrupted index is later used to
access an array, leading to a heap-buffer-overflow. In sqlite3ExprCodeTarget,
the out-of-bounds values are used to construct a potentially invalid
VDBE instruction. In agginfoPersistExprCb, the out-of-bounds index
read from an array [5] is followed by an out-of-bounds write to the
same index [6], leading to memory corruption.
Timeline
--------
Date reported: 2025-06-28
Date fixed: 2025-06-30
Date disclosed: 2025-08-25
[See the above URL for the code excerpt that the [...] references point to
and for further analysis.]
--
-Alan Coopersmith- [email protected]
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
