Segmentation fault on corrupted database

[Even Rouault]

Ubuntu 10.04.4 LTS x86_64
ii libsqlite3-0 3.6.22-1 SQLite 3 shared library
ii sqlite3 3.6.22-1 A command line interface for SQLite 3

Running "sqlite3 byte.gpkg "SELECT * FROM gpkg_tile_matrix WHERE table_name = 'byte'" on the attached sqlite3 database causes a segmentation fault. Removing the WHERE condition avoids the crash. The database has been produced by a fuzzer from a valid database.

With Valgrind :

==16670== Invalid read of size 1
==16670== at 0x4E9B95A: ??? (in /usr/lib/libsqlite3.so.0.8.6)
==16670== by 0x4E87124: sqlite3_step (in /usr/lib/libsqlite3.so.0.8.6)
==16670== by 0x404CEF: ??? (in /usr/bin/sqlite3)
==16670== by 0x407B34: ??? (in /usr/bin/sqlite3)
==16670== by 0x531DC8C: (below main) (libc-start.c:226)
==16670== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16670==
==16670==
==16670== Process terminating with default action of signal 11 (SIGSEGV)
==16670== Access not within mapped region at address 0x0
==16670== at 0x4E9B95A: ??? (in /usr/lib/libsqlite3.so.0.8.6)
==16670== by 0x4E87124: sqlite3_step (in /usr/lib/libsqlite3.so.0.8.6)
==16670== by 0x404CEF: ??? (in /usr/bin/sqlite3)
==16670== by 0x407B34: ??? (in /usr/bin/sqlite3)
==16670== by 0x531DC8C: (below main) (libc-start.c:226)
==16670== If you believe this happened as a result of a stack
==16670== overflow in your program's main thread (unlikely but
==16670== possible), you can try to increase the size of the
==16670== main thread stack using the --main-stacksize= flag.
==16670== The main thread stack size used in this run was 8388608.

Classifying this as potential security vulnerability (Denial of Service ?)