Segmentation fault on corrupted sqlite3 database on 14.04.3 LTS

[Even Rouault]

The following command triggers a Segmentation fault:

$ valgrind sqlite3 test.gpkg "SELECT * FROM gpkg_contents WHERE table_name = 'poly'"
==601== Memcheck, a memory error detector
==601== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==601== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==601== Command: sqlite3 test.gpkg SELECT\ *\ FROM\ gpkg_contents\ WHERE\ table_name\ =\ 'poly'
==601==
==601== Invalid read of size 1
==601== at 0x4EA9061: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==601== by 0x4EABF86: sqlite3_step (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==601== by 0x10DE2D: ??? (in /usr/bin/sqlite3)
==601== by 0x10AF4D: ??? (in /usr/bin/sqlite3)
==601== by 0x5357EC4: (below main) (libc-start.c:287)
==601== Address 0x105ddcd4f is not stack'd, malloc'd or (recently) free'd
==601==
==601==
==601== Process terminating with default action of signal 11 (SIGSEGV)
==601== Access not within mapped region at address 0x105DDCD4F
==601== at 0x4EA9061: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==601== by 0x4EABF86: sqlite3_step (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==601== by 0x10DE2D: ??? (in /usr/bin/sqlite3)
==601== by 0x10AF4D: ??? (in /usr/bin/sqlite3)
==601== by 0x5357EC4: (below main) (libc-start.c:287)
==601== If you believe this happened as a result of a stack
==601== overflow in your program's main thread (unlikely but
==601== possible), you can try to increase the size of the
==601== main thread stack using the --main-stacksize= flag.
==601== The main thread stack size used in this run was 8388608.
==601==
==601== HEAP SUMMARY:
==601== in use at exit: 196,267 bytes in 1,176 blocks
==601== total heap usage: 1,975 allocs, 799 frees, 481,840 bytes allocated
==601==
==601== LEAK SUMMARY:
==601== definitely lost: 0 bytes in 0 blocks
==601== indirectly lost: 0 bytes in 0 blocks
==601== possibly lost: 196,256 bytes in 1,175 blocks
==601== still reachable: 11 bytes in 1 blocks
==601== suppressed: 0 bytes in 0 blocks
==601== Rerun with --leak-check=full to see details of leaked memory
==601==
==601== For counts of detected and suppressed errors, rerun with: -v
==601== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

$ dpkg -l | grep sqlite3
ii libsqlite3-0:amd64 3.8.2-1ubuntu2.1 amd64 SQLite 3 shared library
ii libsqlite3-0:i386 3.8.2-1ubuntu2.1 i386 SQLite 3 shared library
ii libsqlite3-dev:amd64 3.8.2-1ubuntu2.1 amd64 SQLite 3 development files
ii sqlite3 3.8.2-1ubuntu2.1 amd64 Command line interface for SQLite 3

It seems security patches must be missing as the same database with latest self-compiled sqlite 3.9.2 outputs:

$ sqlite-autoconf-3090200/sqlite3 test.gpkg "SELECT * FROM gpkg_contents WHERE table_name = 'poly'"
Error: database disk image is malformed

[Seth Arnold (seth-arnold)]

Even, is this database free to be shared publicly? Or should we keep it private?

Thanks

Precise:
Get:1 http://mirrors.kernel.org/ubuntu/ precise-updates/main sqlite3 amd64 3.7.9-2ubuntu1.2 [26.8 kB]
$ sqlite3 test.gpkg "SELECT * FROM gpkg_contents WHERE table_name = 'poly'"
Error: no such table: gpkg_contents

Trusty:
Get:1 http://mirrors.kernel.org/ubuntu/ trusty-updates/main sqlite3 amd64 3.8.2-1ubuntu2.1 [28.8 kB]
$ sqlite3 test.gpkg "SELECT * FROM gpkg_contents WHERE table_name = 'poly'"
Segmentation fault (core dumped)

Vivid:
Get:1 http://mirrors.kernel.org/ubuntu/ vivid-updates/main sqlite3 amd64 3.8.7.4-1ubuntu0.1 [33.2 kB]
$ sqlite3 test.gpkg "SELECT * FROM gpkg_contents WHERE table_name = 'poly'"
Error: database disk image is malformed

Wily:
Get:1 http://mirrors.kernel.org/ubuntu/ wily/main sqlite3 amd64 3.8.11.1-1 [36.2 kB]
$ sqlite3 test.gpkg "SELECT * FROM gpkg_contents WHERE table_name = 'poly'"
Error: database disk image is malformed

[Even Rouault (even-rouault)]

It is public domain. It is the result of the conversion of poly.shp from the GDAL autotest suite ( http://svn.osgeo.org/gdal/trunk/autotest/ogr/data/poly.shp ) to the GPKG format (which uses a SQLite3 container). I forgot to mention the corrupted database was generated with AFL ( http://lcamtuf.coredump.cx/afl/ ).