Public bug reported: 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 ?) ** Affects: sqlite3 (Ubuntu) Importance: Undecided Status: New ** Attachment added: "byte.gpkg" https://bugs.launchpad.net/bugs/1402291/+attachment/4280576/+files/byte.gpkg -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sqlite3 in Ubuntu. https://bugs.launchpad.net/bugs/1402291 Title: Segmentation fault on corrupted database Status in sqlite3 package in Ubuntu: New Bug description: 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 ?) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sqlite3/+bug/1402291/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp