SQLite before 3.32.0 allows a virtual table to be renamed to the name of one of its shadow tables, related to alter.c and build.c. Reference and upstream commit: https://sqlite.org/src/info/eca0ba2cf4c0fdf7
Created mingw-sqlite tracking bugs for this issue: Affects: fedora-all [bug 1841569] Created sqlite tracking bugs for this issue: Affects: fedora-all [bug 1841571] Created sqlite2 tracking bugs for this issue: Affects: fedora-all [bug 1841570]
https://www.sqlite.org/vtab.html#xshadowname: """ Some virtual table implementations (ex: FTS3, FTS5, and RTREE) make use of real (non-virtual) database tables to store content. For example, when content is inserted into the FTS3 virtual table, the data is ultimately stored in real tables named "%_content", "%_segdir", "%_segments", "%_stat", and "%_docsize" where "%" is the name of the original virtual table. This auxiliary real tables that store content for a virtual table are called shadow tables. """ My understanding is that a virtual table is not supposed to be renamed to one of its shadow tables to avoid possible corruption of the underlying data. SQLite needs to differentiate a virtual table from its shadow tables in order to protect the content of the shadow tables from being corrupted (although it's not clear to me what a concrete attack scenario would look like). Anyway, to exploit this issue an attacker would need to have a level of access that allows him to execute SQL statements to rename the virtual tables.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:4442 https://access.redhat.com/errata/RHSA-2020:4442
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-13631
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