sqlite3Select in select.c in SQLite 3.30.1 allows a crash if a sub-select uses both DISTINCT and window functions, and also has certain ORDER BY usage. Reference and upstream commit: https://github.com/sqlite/sqlite/commit/e59c562b3f6894f84c715772c4b116d7b5c01348
Created mingw-sqlite tracking bugs for this issue: Affects: epel-7 [bug 1777951] Affects: fedora-all [bug 1777952] Created sqlite tracking bugs for this issue: Affects: fedora-all [bug 1777950]
The crash is due to the assertion statement "assert( memIsValid(pRec) );" in function sqlite3VdbeExec() in vdbe.c. pRec is a pointer to a "Mem" struct used to represent SQL values that can be stored in a database table (e.g., integers, floating point values, strings, etc). memIsValid() is a macro defined in vdbeInt.h which checks if a Mem object represents a valid value (i.e., flag "MEM_Undefined" is not set). It is worth noting that memIsValid() is supposed to be used inside assertion statements only, and those statements are disabled by default: "NDEBUG and SQLITE_DEBUG are opposites [..] Setting NDEBUG makes the code smaller and faster by disabling the assert() statements in the code. So we want the default action to be for NDEBUG to be set and NDEBUG to be undefined only if SQLITE_DEBUG is set". The versions of sqlite as shipped with Red Hat Enterprise Linux are compiled without SQLITE_DEBUG, so it's not possible to reproduce the crash. The invalid Mem object may still lead to undefined behaviors, though no notable defects have been observed so far.
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-2019-19244
Although it is not possible to reproduce the crash due to the missing assert statement, the assert condition is violated leading to undefined behaviors (e.g., use of uninitialized values). For this reason the bug has been reopened.