Null pointer dereference on '.dump' or 'SELECT * FROM sqlite_master' on corrupted file
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
sqlite3 (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
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_
==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/
==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: sqlite3LockAndP
==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: sqlite3LockAndP
==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_
if( !hDB )
return 1;
sqlite3_
sqlite3_
sqlite3_
return 0;
}
}}}
$ gcc -Wall mytest.c -o mytest -lsqlite3
$ valgrind ./mytest gdal_ossfuzz_
==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/
==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: sqlite3LockAndP
==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:/
{{{
fee0225c9505200
commit fee0225c9505200
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 84229496991a77e
}}}
This issue was initially found with oss-fuzz on GDAL per https:/
I'm emailing privately Richard Hipp <email address hidden> with this report.
CVE References
information type: | Private Security → Public Security |
Changed in sqlite3 (Ubuntu): | |
status: | New → Confirmed |
Richard Hipp just committed a fix in sqlite master. Apparently this must be https:/ /www.sqlite. org/cgi/ src/timeline? r=corrupt- schema