Segmentation fault on corrupted sqlite3 database on 14.04.3 LTS
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
sqlite3 (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
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/
==601== by 0x4EABF86: sqlite3_step (in /usr/lib/
==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/
==601== by 0x4EABF86: sqlite3_step (in /usr/lib/
==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-
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-
Error: database disk image is malformed
information type: | Private Security → Public Security |
Even, is this database free to be shared publicly? Or should we keep it private?
Thanks
Precise: mirrors. kernel. org/ubuntu/ precise- updates/ main sqlite3 amd64 3.7.9-2ubuntu1.2 [26.8 kB]
Get:1 http://
$ sqlite3 test.gpkg "SELECT * FROM gpkg_contents WHERE table_name = 'poly'"
Error: no such table: gpkg_contents
Trusty: mirrors. kernel. org/ubuntu/ trusty-updates/main sqlite3 amd64 3.8.2-1ubuntu2.1 [28.8 kB]
Get:1 http://
$ sqlite3 test.gpkg "SELECT * FROM gpkg_contents WHERE table_name = 'poly'"
Segmentation fault (core dumped)
Vivid: mirrors. kernel. org/ubuntu/ vivid-updates/main sqlite3 amd64 3.8.7.4-1ubuntu0.1 [33.2 kB]
Get:1 http://
$ sqlite3 test.gpkg "SELECT * FROM gpkg_contents WHERE table_name = 'poly'"
Error: database disk image is malformed
Wily: mirrors. kernel. org/ubuntu/ wily/main sqlite3 amd64 3.8.11.1-1 [36.2 kB]
Get:1 http://
$ sqlite3 test.gpkg "SELECT * FROM gpkg_contents WHERE table_name = 'poly'"
Error: database disk image is malformed