SQLite 3.34.1 fixes a potential use-after-free bug when processing a subquery with both a correlated WHERE clause and a "HAVING 0" clause and where the parent query is an aggregate.
"The WHERE clause (a=2), uses an aggregate column from the outer query.
If the HAVING term (0) is moved into the WHERE clause in this case,
SQLite would at one point optimize (a=2 AND 0) to simply (0). Which
is logically correct, but happened to cause problems in aggregate
processing for the outer query."
To ensure that the condition HAVING 0 is considered, the upstream patch adds the ExprAlwaysFalse(pExpr)==0 check to the if statement before the business logic in havingToWhereExprCb() in file src/select.c.
This flaw could allow an attacker who has permission to run SQL queries on the sqlite database to cause a denial of service, or possibly code execution if they are able to control the re-used memory.
This flaw has been marked Moderate because in order to run such a query, a user would need to already have access to query the data in the database.
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
Created mingw-sqlite tracking bugs for this issue:
Affects: fedora-all [bug 1924915]
Created sqlite tracking bugs for this issue:
Affects: fedora-all [bug 1924914]
SQLite as shipped in Red Hat Enterprise Linux 6, 7 and 8 is not affected by this flaw as the code was introduced in a newer version of SQLite than that shipped. This flaw has been marked Moderate because in order to run such a query, a user would need to already have access to query the data in the database.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):