Null pointer dereference on '.dump' or 'SELECT * FROM sqlite_master' on corrupted file

[Even Rouault]

Starting with sqlite 3.7.10 and up to latest sqlite 3.22.0/master, the following on the attached database causes a segmentation fault.
I can reproduce this on Ubuntu Xenial 16.04 with libsqlite3-0:amd64 3.11.0-1ubuntu1. Should also affect Ubuntu Trusty that ship with sqlite 3.8.2

$ echo ".dump" | valgrind sqlite3 gdal_ossfuzz_6964.db

==12781== Memcheck, a memory error detector
==12781== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==12781== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==12781== Command: .libs/sqlite3 /home/even/gdal/trunk/gdal/gdal_ossfuzz_6964.db
==12781==
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
==12781== Invalid read of size 8
==12781== at 0x4E9302B: sqlite3EndTable (sqlite3.c:82695)
==12781== by 0x4EC129A: yy_reduce (sqlite3.c:109734)
==12781== by 0x4EC4A2E: sqlite3Parser (sqlite3.c:110900)
==12781== by 0x4EC5896: sqlite3RunParser (sqlite3.c:111737)
==12781== by 0x4EA6FC2: sqlite3Prepare (sqlite3.c:94064)
==12781== by 0x4EA731F: sqlite3LockAndPrepare (sqlite3.c:94156)
==12781== by 0x4EA74B7: sqlite3_prepare (sqlite3.c:94219)
==12781== by 0x4EA61C6: sqlite3InitCallback (sqlite3.c:93538)
==12781== by 0x4EA1FDE: sqlite3_exec (sqlite3.c:90752)
==12781== by 0x4EA68AB: sqlite3InitOne (sqlite3.c:93784)
==12781== by 0x4EA6A96: sqlite3Init (sqlite3.c:93850)
==12781== by 0x4EA6B94: sqlite3ReadSchema (sqlite3.c:93887)
==12781== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==12781==
==12781==
==12781== Process terminating with default action of signal 11 (SIGSEGV)
==12781== Access not within mapped region at address 0x0
==12781== at 0x4E9302B: sqlite3EndTable (sqlite3.c:82695)
==12781== by 0x4EC129A: yy_reduce (sqlite3.c:109734)
==12781== by 0x4EC4A2E: sqlite3Parser (sqlite3.c:110900)
==12781== by 0x4EC5896: sqlite3RunParser (sqlite3.c:111737)
==12781== by 0x4EA6FC2: sqlite3Prepare (sqlite3.c:94064)
==12781== by 0x4EA731F: sqlite3LockAndPrepare (sqlite3.c:94156)
==12781== by 0x4EA74B7: sqlite3_prepare (sqlite3.c:94219)
==12781== by 0x4EA61C6: sqlite3InitCallback (sqlite3.c:93538)
==12781== by 0x4EA1FDE: sqlite3_exec (sqlite3.c:90752)
==12781== by 0x4EA68AB: sqlite3InitOne (sqlite3.c:93784)
==12781== by 0x4EA6A96: sqlite3Init (sqlite3.c:93850)
==12781== by 0x4EA6B94: sqlite3ReadSchema (sqlite3.c:93887)

This is a bug of the library and not the shell since the same occurs on this trivial C file

mytest.c:

{{{
#include <sqlite3.h>

int main(int argc, char* argv[])
{
    sqlite3* hDB = 0;
    int nRowCount = 0, nColCount = 0;
    char** papszResult = 0;
    sqlite3_open(argv[1], &hDB);
    if( !hDB )
        return 1;
    sqlite3_get_table( hDB, "SELECT * FROM sqlite_master",
                       &papszResult, &nRowCount, &nColCount,
                       0 );
    sqlite3_free_table(papszResult);
    sqlite3_close(hDB);
    return 0;
}
}}}

$ gcc -Wall mytest.c -o mytest -lsqlite3

$ valgrind ./mytest gdal_ossfuzz_6964.db
==24793== Memcheck, a memory error detector
==24793== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==24793== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==24793== Command: ./mytest /home/even/gdal/trunk/gdal/gdal_ossfuzz_6964.db
==24793==
==24793== Invalid read of size 8
==24793== at 0x4E9302B: sqlite3EndTable (sqlite3.c:82695)
==24793== by 0x4EC129A: yy_reduce (sqlite3.c:109734)
==24793== by 0x4EC4A2E: sqlite3Parser (sqlite3.c:110900)
==24793== by 0x4EC5896: sqlite3RunParser (sqlite3.c:111737)
==24793== by 0x4EA6FC2: sqlite3Prepare (sqlite3.c:94064)
==24793== by 0x4EA731F: sqlite3LockAndPrepare (sqlite3.c:94156)
==24793== by 0x4EA74B7: sqlite3_prepare (sqlite3.c:94219)
==24793== by 0x4EA61C6: sqlite3InitCallback (sqlite3.c:93538)
==24793== by 0x4EA1FDE: sqlite3_exec (sqlite3.c:90752)
==24793== by 0x4EA68AB: sqlite3InitOne (sqlite3.c:93784)
==24793== by 0x4EA6A96: sqlite3Init (sqlite3.c:93850)
==24793== by 0x4EA6B94: sqlite3ReadSchema (sqlite3.c:93887)
==24793== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==24793==

Based on the git clone at
https://github.com/mackyle/sqlite, I've bisected the first bad commit to be
{{{
fee0225c95052006f0776d837eeafd26b857db53 is the first bad commit
commit fee0225c95052006f0776d837eeafd26b857db53
Author: D. Richard Hipp <email address hidden>
Date: Wed Jan 11 15:47:42 2012 +0000

    Make the pager less vulnerable to problems caused by shifting sector sizes
    when rolling back a hot journal.

:040000 040000 84229496991a77e9600cadd39237de4f48cc9180 b374865f1168e3832fbf3e54c61704ae3c03c27e M src
}}}

This issue was initially found with oss-fuzz on GDAL per https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6964 . Credit to OSS-Fuzz

I'm emailing privately Richard Hipp <email address hidden> with this report.

[Even Rouault (even-rouault)]

Richard Hipp just committed a fix in sqlite master. Apparently this must be https://www.sqlite.org/cgi/src/timeline?r=corrupt-schema

[Seth Arnold (seth-arnold)]

Use CVE-2018-8740.

Thanks Even and Richard.