SQLite 3.30.1 mishandles pExpr->y.pTab, as demonstrated by the TK_COLUMN case in sqlite3ExprCodeTarget in expr.c. Reference and upstream commit: https://github.com/sqlite/sqlite/commit/57f7ece78410a8aae86aa4625fb7556897db384c
Created mingw-sqlite tracking bugs for this issue: Affects: epel-7 [bug 1778870] Affects: fedora-all [bug 1778869] Created sqlite tracking bugs for this issue: Affects: fedora-all [bug 1778868]
There's an issue with SQLite when using a generated column which is evaluated to a constant value as index for a table. When evaluating the SQL expression containing a join clause referencing the generated column, an internal field representing the tables involved on the join is set to NULL. However, due to an error in the logic used during expression evaluation the same field is further dereferenced leading to an NULL pointer dereference. An attack may leverage this flaw to cause DoS. The Attack Complexity may be considered high as the attack needs to triage the existance of a table with such schema, a query with the aspects mentioned above and a way to trigger it. The availability impact when an attack is successful may be considered High.
Please, can you provide a reproducer for this issue ? There is a problem with backporting the fix. Thank you
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-19242