SQLite through 3.32.0 has an integer overflow in sqlite3_str_vappendf in printf.c. References and upstream commit: https://www.sqlite.org/src/info/23439ea582241138 https://www.sqlite.org/src/info/d08d3405878d394e
Created mingw-sqlite tracking bugs for this issue: Affects: fedora-all [bug 1841225] Created sqlite tracking bugs for this issue: Affects: fedora-all [bug 1841227] Created sqlite2 tracking bugs for this issue: Affects: epel-all [bug 1841224] Affects: fedora-all [bug 1841226]
Statement: This flaw did not affect the versions of SQLite as shipped with Red Hat Enterprise Linux 7 as they did not include support for the printf() function, which was introduced in a later version of the package.
printf() was introduced in SQLite upstream version 3.8.3 via the following commit: -> https://github.com/sqlite/sqlite/commit/a5c1416d64b4b857721f085258b6ef1dcaeb6f5b
Under some circumstances, when performing floating-point conversions it is possible to cause an integer overflow in the SQL printf() function, resulting in a stack-based buffer overflow. Consider the following excerpt from sqlite3_str_vappendf() in printf.c: ``` char *bufpt; /* Pointer to the conversion buffer */ char buf[etBUFSIZE]; /* Conversion buffer, etBUFSIZE == 70 */ ... bufpt = buf; ... if( exp<-4 || exp>precision ){ xtype = etEXP; }else{ precision = precision - exp; xtype = etFLOAT; } ... /* Size of a temporary buffer needed */ szBufNeeded = MAX(e2,0)+(i64)precision+(i64)width+15; if( szBufNeeded > etBUFSIZE ){ ... } ... /* Significant digits after the decimal point */ while( (precision--)>0 ){ *(bufpt++) = et_getdigit(&realvalue,&nsd); } ``` A format string can be crafted so that precision == 2147483646 and exp == -2. This causes an integer overflow on the precision variable (due to 2147483646-(-2) = 2147483648 = 0x80000000) leading to the computation of a negative buffer size. In turn, this leads to the overflow of the conversion buffer. Note that the conversion buffer is incrementally populated with the ascii code of the digits after the decimal point (up to the 16th digit, after which '0' is always returned).
SQLite provides the compile-time option SQLITE_PRINTF_PRECISION_LIMIT to protect against similar attacks. Note that the versions of SQLite as shipped with Red Hat Enterprise Linux 7 and 8 were *not* compiled with that preprocessor option.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:1581 https://access.redhat.com/errata/RHSA-2021:1581
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-13434
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:1968 https://access.redhat.com/errata/RHSA-2021:1968