Bug#736463: libsqlite3-0: UNIQUE PRIMARY KEY + WITHOUT ROWID = segfault
Package: libsqlite3-dev
Version: 3.8.7.1-1+deb8u1
Followup-For: Bug #736463
(was sent to unrelated bug, resenting, sorry)
1) I was able to reproduce this bug in jessie's 3.8.7.1 (gdb and
valgrind report attached);
2) I was *NOT* able to reproduce it in (self-backported) sid's
3.8.10.2-1 (and running under valgrind does not show any problem).
[fwiw, test.db created by sid {totally expectdly} kills jessie's sqlite3
on attempt to open it].
However, I have not found respective entry in changelogs (or upstream
commit), so this could be false positive.
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libsqlite3-dev depends on:
ii libc6-dev 2.19-18
ii libsqlite3-0 3.8.7.1-1+deb8u1
libsqlite3-dev recommends no packages.
Versions of packages libsqlite3-dev suggests:
ii sqlite3-doc 3.8.7.1-1+deb8u1
-- no debconf information
$ valgrind sqlite3 test.db CREATE TABLE t ( x UNIQUE PRIMARY KEY ) WITHOUT ROWID;
==7586== Memcheck, a memory error detector
==7586== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7586== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==7586== Command: sqlite3 test.db CREATE\ TABLE\ t\ (\ x\ UNIQUE\ PRIMARY\ KEY\ )\ WITHOUT\ ROWID;
==7586==
==7586== Invalid read of size 1
==7586==at 0x48E8AF9: sqlite3EndTable (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CAAF7: sqlite3Parser (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CE7BB: sqlite3RunParser (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CEE64: sqlite3Prepare (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CF224: sqlite3LockAndPrepare (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x10E603: shell_exec.constprop.10 (in /usr/bin/sqlite3)
==7586==by 0x10A78E: main (in /usr/bin/sqlite3)
==7586== Address 0x37 is not stack'd, malloc'd or (recently) free'd
==7586==
==7586==
==7586== Process terminating with default action of signal 11 (SIGSEGV)
==7586== Access not within mapped region at address 0x37
==7586==at 0x48E8AF9: sqlite3EndTable (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CAAF7: sqlite3Parser (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CE7BB: sqlite3RunParser (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CEE64: sqlite3Prepare (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CF224: sqlite3LockAndPrepare (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x10E603: shell_exec.constprop.10 (in /usr/bin/sqlite3)
==7586==by 0x10A78E: main (in /usr/bin/sqlite3)
==7586== If you believe this happened as a result of a stack
==7586== overflow in your program's main thread (unlikely but
==7586== possible), you can try to increase the size of the
==7586== main thread stack using the --main-stacksize= flag.
==7586== The main thread stack size used in this run was 8388608.
==7586==
==7586== HEAP SUMMARY:
==7586== in use at exit: 75,860 bytes in 101 blocks
==7586== total heap usage: 262 allocs, 161 frees, 101,111 bytes allocated
==7586==
==7586== LEAK SUMMARY:
==7586==definitely lost: 0 bytes in 0 blocks
==7586==indirectly lost: 0 bytes in 0 blocks
==7586== possibly lost: 75,848 bytes in 100 blocks
==7586==still reachable: 12 bytes in 1 blocks
==7586== suppressed: 0 bytes in 0 blocks
==7586== Rerun with --leak-check=full to see details of leaked memory
==7586==
==7586== For counts of detected and suppressed errors, rerun with: -v
==7586== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
(gdb) run
Starting program: /usr/bin/sqlite3 test.db CREATE\ TABLE\ t\ \(\ x\ UNIQUE\ PRIMARY\ KEY\ \)\ WITHOUT\ ROWID\;
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/i386-linux-gnu/i686/cmov/libthread_db.so.1.
Program received signal SIGSEGV, Segmentation fault.
convertToWithoutRowidTable (pTab=0x5657b7c0, pParse=0x5657aa78)
at sqlite3.c:90230
90230 sqlite3.c: No such file or directory.
(gdb) bt full
#0 convertToWithoutRowidTable (pTab=0x5657b7c0, pParse=0x5657aa78)
at sqlite3.c:90230
pPk = 0x0
nPk = optimized out
i = optimized out
db = 0x56568010
pIdx = optimized out
j = optimized out
v = optimized out
#1 sqlite3EndTable (pParse=0x5657aa78, pCons=0x5657ad00, pEnd=0x5657ad10,
tabOpts=32 ' ', pSelect=0x0) at sqlite3.c:24813
p = 0x5657b7c0
db = 0x56568010
pIdx = optimized out
#2 0xf7f46af8 in yy_reduce (yyruleno=optimized out,
Bug#736463: libsqlite3-0: UNIQUE PRIMARY KEY + WITHOUT ROWID = segfault
On 14.07.2015 14:36, László Böszörményi (GCS) wrote:
On Tue, Jul 14, 2015 at 11:41 AM, Yuriy M. Kaminskiy yum...@gmail.com wrote:
Package: libsqlite3-dev
Version: 3.8.7.1-1+deb8u1
Followup-For: Bug #736463
(was sent to unrelated bug, resenting, sorry)
1) I was able to reproduce this bug in jessie's 3.8.7.1 (gdb and valgrind
report attached);
2) I was *NOT* able to reproduce it in (self-backported) sid's 3.8.10.2-1
(and running under valgrind does not show any problem).
[fwiw, test.db created by sid {totally expectdly} kills jessie's sqlite3 on
attempt to open it].
However, I have not found respective entry in changelogs (or upstream
commit), so this could be false positive.
I can only repeat that the quick solution to remove UNIQUE, the
PRIMARY KEY itself guarantee that the specified column will be unique.
:shrug:
There should be no problem with attempt to open a database file obtained
from untrusted source, right? It's just data, no executable code[*],
etc, right?
Then try to open attached database with jessie's sqlite3.
Or feed it to mozilla (IIRC, there are javascript binding?)
That is, this is a security problem.
(The fact that UNIQUE constraint is redundant with PRIMARY KEY is
completely irrelevant here; e.g. it can be autogenerated code, database
should handle that gracefully anyway).
[*] well, almost; there are triggers, but their side effects are limited
to altering the database.
test.db
Description: Binary data
Bug#736463: libsqlite3-0: UNIQUE PRIMARY KEY + WITHOUT ROWID = segfault
On Tue, Jul 14, 2015 at 11:41 AM, Yuriy M. Kaminskiy yum...@gmail.com wrote:
Package: libsqlite3-dev
Version: 3.8.7.1-1+deb8u1
Followup-For: Bug #736463
(was sent to unrelated bug, resenting, sorry)
1) I was able to reproduce this bug in jessie's 3.8.7.1 (gdb and valgrind
report attached);
2) I was *NOT* able to reproduce it in (self-backported) sid's 3.8.10.2-1
(and running under valgrind does not show any problem).
[fwiw, test.db created by sid {totally expectdly} kills jessie's sqlite3 on
attempt to open it].
However, I have not found respective entry in changelogs (or upstream
commit), so this could be false positive.
I can only repeat that the quick solution to remove UNIQUE, the
PRIMARY KEY itself guarantee that the specified column will be unique.
Cheers,
Laszlo/GCS
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736463: libsqlite3-0: UNIQUE PRIMARY KEY + WITHOUT ROWID = segfault
control: tag -1 patch
thanks
On 14.07.2015 15:34, Yuriy M. Kaminskiy wrote:
On 14.07.2015 14:36, László Böszörményi (GCS) wrote:
On Tue, Jul 14, 2015 at 11:41 AM, Yuriy M. Kaminskiy
yum...@gmail.com wrote:
Package: libsqlite3-dev
Version: 3.8.7.1-1+deb8u1
Followup-For: Bug #736463
(was sent to unrelated bug, resenting, sorry)
1) I was able to reproduce this bug in jessie's 3.8.7.1 (gdb and
valgrind
report attached);
2) I was *NOT* able to reproduce it in (self-backported) sid's
3.8.10.2-1
(and running under valgrind does not show any problem).
[fwiw, test.db created by sid {totally expectdly} kills jessie's
sqlite3 on attempt to open it].
However, I have not found respective entry in changelogs (or upstream
commit), so this could be false positive.
I can only repeat that the quick solution to remove UNIQUE, the
PRIMARY KEY itself guarantee that the specified column will be unique.
:shrug:
There should be no problem with attempt to open a database file
obtained from untrusted source, right? It's just data, no executable
code[*], etc, right?
Then try to open attached database with jessie's sqlite3.
Or feed it to mozilla (IIRC, there are javascript binding?)
That is, this is a security problem.
(The fact that UNIQUE constraint is redundant with PRIMARY KEY is
completely irrelevant here; e.g. it can be autogenerated code,
database should handle that gracefully anyway).
[*] well, almost; there are triggers, but their side effects are
limited to altering the database.
Apparently, this commit: http://www.sqlite.org/src/info/d871a7921722bb0f
(included in 3.8.9) plugged SIGSEGV.
However, this commit (not yet in any released version):
http://www.sqlite.org/src/info/3b936913f3dc2cae
suggest that d871a probably was insufficient/broken in some subtle way
(and, indeed, I see corruption in patched 3.8.7.1 and [unpatched]
3.8.10.2, triggered by sql code from 3b936 test suite).
That said, I think d871a792 is probably sufficient for stable (sigsegv
plugged, rest is outside of stable scope).
Upstream: http://www.sqlite.org/src/info/d871a7921722bb0f
Closes: #736463
Index: sqlite3-3.8.7.1/src/build.c
===
--- sqlite3-3.8.7.1.orig/src/build.c
+++ sqlite3-3.8.7.1/src/build.c
@@ -3168,6 +3168,7 @@ Index *sqlite3CreateIndex(
pIdx-onError = pIndex-onError;
}
}
+pRet = pIdx;
goto exit_create_index;
}
}
Bug#736463: libsqlite3-0: UNIQUE PRIMARY KEY + WITHOUT ROWID = segfault
Package: libsqlite3-0 Version: 3.8.2-1 Severity: normal Attempting to create a table which has a UNIQUE PRIMARY KEY and is also WITHOUT ROWID causes an immediate crash. Rereading the documentation reveals that UNIQUE is in fact redundant to PRIMARY KEY, so I don't actually need this to work, but regardless it should not crash. (sqlite is in general fine with UNIQUE PRIMARY KEY; it's just the combination of that and WITHOUT ROWID that crashes.) To reproduce: $ gdb --args sqlite3 test.db CREATE TABLE t ( x UNIQUE PRIMARY KEY ) WITHOUT ROWID; GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/sqlite3...Reading symbols from /usr/lib/debug/.build-id/3a/01d762213ac60b3ab2d8d66e8cf1473fbbfe2d.debug...done. done. (gdb) r Starting program: /usr/bin/sqlite3 test.db CREATE\ TABLE\ t\ \(\ x\ UNIQUE\ PRIMARY\ KEY\ \)\ WITHOUT\ ROWID\; warning: no loadable sections found in added symbol-file system-supplied DSO at 0x77ffa000 warning: Could not load shared library symbols for linux-vdso.so.1. Do you need set solib-search-path or set sysroot? [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. convertToWithoutRowidTable (pTab=0x55778948, pParse=0x55776ba8) at sqlite3.c:85911 85911 sqlite3.c: No such file or directory. (gdb) bt #0 convertToWithoutRowidTable (pTab=0x55778948, pParse=0x55776ba8) at sqlite3.c:85911 #1 sqlite3EndTable (pParse=pParse@entry=0x55776ba8, pCons=pCons@entry=0x55776f10, pEnd=pEnd@entry=0x55776f30, tabOpts=optimized out, pSelect=pSelect@entry=0x0) at sqlite3.c:20492 #2 0x77b87963 in yy_reduce (yyruleno=32, yypParser=0x55776ba8) at sqlite3.c:116504 #3 sqlite3Parser (yyp=yyp@entry=0x55776e58, yymajor=optimized out, yyminor=..., pParse=pParse@entry=0x55776ba8) at sqlite3.c:52191 #4 0x77b8b6fc in sqlite3RunParser (pParse=pParse@entry=0x55776ba8, zSql=zSql@entry=0x7fffe5e1 CREATE TABLE t ( x UNIQUE PRIMARY KEY ) WITHOUT ROWID;, pzErrMsg=pzErrMsg@entry=0x7fffca68) at sqlite3.c:118552 #5 0x77b8bd32 in sqlite3Prepare (db=db@entry=0x55763038, zSql=zSql@entry=0x7fffe5e1 CREATE TABLE t ( x UNIQUE PRIMARY KEY ) WITHOUT ROWID;, nBytes=nBytes@entry=-1, saveSqlFlag=saveSqlFlag@entry=1, pReprepare=pReprepare@entry=0x0, ppStmt=ppStmt@entry=0x7fffcb80, pzTail=pzTail@entry=0x7fffcb88) at sqlite3.c:99204 #6 0x77b8bfe5 in sqlite3LockAndPrepare (db=0x55763038, zSql=0x7fffe5e1 CREATE TABLE t ( x UNIQUE PRIMARY KEY ) WITHOUT ROWID;, nBytes=-1, saveSqlFlag=1, pOld=0x0, ppStmt=0x7fffcb80, pzTail=0x7fffcb88) at sqlite3.c:99296 #7 0x77b8c278 in sqlite3_prepare_v2 (db=db@entry=0x55763038, zSql=zSql@entry=0x7fffe5e1 CREATE TABLE t ( x UNIQUE PRIMARY KEY ) WITHOUT ROWID;, nBytes=nBytes@entry=-1, ppStmt=ppStmt@entry=0x7fffcb80, pzTail=pzTail@entry=0x7fffcb88) at sqlite3.c:99372 #8 0x9dd6 in shell_exec (db=0x55763038, zSql=zSql@entry=0x7fffe5e1 CREATE TABLE t ( x UNIQUE PRIMARY KEY ) WITHOUT ROWID;, pArg=pArg@entry=0x7fffcc80, pzErrMsg=pzErrMsg@entry=0x7fffcc78, xCallback=0x8fe0 shell_callback) at ./src/shell.c:1274 #9 0x6f2e in main (argc=3, argv=0x7fffe308) at ./src/shell.c:3511 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (501, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libsqlite3-0 depends on: ii libc6 2.17-97 ii multiarch-support 2.17-97 libsqlite3-0 recommends no packages. libsqlite3-0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
