One more find. Tested on 64-bit x86 Linux box, version 3.8.8.1.

printf "create table t0(\211 DEFAULT(0=0)NOT/**/NULL);REPLACE into t0
select'';" >test.sql

./sqlite_asan <test.sql

This does not crash under normal conditions, but both ASAN and
Valgrind claim an out-of-bound read, so they are probably not wrong.

ASAN:

ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60800000b898 at pc 0x00000090427c bp 0x7fffffff1cf0 sp
0x7fffffff1ce8
READ of size 8 at 0x60800000b898 thread T0
    #0 0x90427b in sqlite3ExprCollSeq
(/home/lcamtuf/afl/BIN/sqlite3_asan+0x90427b)
    #1 0x98e96a in sqlite3BinaryCompareCollSeq
(/home/lcamtuf/afl/BIN/sqlite3_asan+0x98e96a)
    #2 0x96f78b in codeCompare (/home/lcamtuf/afl/BIN/sqlite3_asan+0x96f78b)
    #3 0x97c15c in sqlite3ExprCodeTarget
(/home/lcamtuf/afl/BIN/sqlite3_asan+0x97c15c)
    #4 0x977fae in sqlite3ExprCode (/home/lcamtuf/afl/BIN/sqlite3_asan+0x977fae)
    #5 0x9c11b3 in sqlite3GenerateConstraintChecks
(/home/lcamtuf/afl/BIN/sqlite3_asan+0x9c11b3)
    #6 0x8a87a2 in sqlite3Insert (/home/lcamtuf/afl/BIN/sqlite3_asan+0x8a87a2)
    #7 0x83f810 in yy_reduce (/home/lcamtuf/afl/BIN/sqlite3_asan+0x83f810)
    ...

0x60800000b898 is located 32 bytes to the right of 88-byte region
[0x60800000b820,0x60800000b878)
allocated by thread T0 here:
    #0 0x49d9cb in __interceptor_malloc
/root/COMP/llvm-3.5.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3
    #1 0x7e5cb1 in sqlite3MemMalloc
(/home/lcamtuf/afl/BIN/sqlite3_asan+0x7e5cb1)
    #2 0xc5c7b7 in mallocWithAlarm (/home/lcamtuf/afl/BIN/sqlite3_asan+0xc5c7b7)
    #3 0x4f74bb in sqlite3Malloc (/home/lcamtuf/afl/BIN/sqlite3_asan+0x4f74bb)
    #4 0x557a99 in sqlite3DbMallocRaw
(/home/lcamtuf/afl/BIN/sqlite3_asan+0x557a99)
    #5 0x91d2ba in exprDup (/home/lcamtuf/afl/BIN/sqlite3_asan+0x91d2ba)
    #6 0x918e69 in sqlite3ExprDup (/home/lcamtuf/afl/BIN/sqlite3_asan+0x918e69)
    #7 0x859923 in sqlite3AddDefaultValue
(/home/lcamtuf/afl/BIN/sqlite3_asan+0x859923)
    ...

Valgrind:

==16603== Invalid read of size 8
==16603==    at 0x5D8670: sqlite3ExprCollSeq (sqlite3.c:81927)
==16603==    by 0x60F29A: codeCompare (sqlite3.c:82059)
==16603==    by 0x6B39F5: sqlite3ExprCodeTarget (sqlite3.c:84448)
==16603==    by 0x6B8A01: sqlite3ExprCode (sqlite3.c:85009)
==16603==    by 0x411402: sqlite3GenerateConstraintChecks (sqlite3.c:99766)
==16603==    by 0x78C1BE: sqlite3Insert (sqlite3.c:99507)
==16603==    by 0x7AD4B5: sqlite3Parser (sqlite3.c:124334)
==16603==    by 0x7BE668: sqlite3RunParser (sqlite3.c:125943)
==16603==    by 0x7C1129: sqlite3Prepare (sqlite3.c:105025)
==16603==    by 0x7C25D0: sqlite3LockAndPrepare.part.504 (sqlite3.c:105120)
==16603==    by 0x7C800D: sqlite3_prepare_v2 (sqlite3.c:105115)
==16603==    by 0x425315: shell_exec.constprop.11 (shell.c:1433)
==16603==  Address 0x5635c68 is 24 bytes before a block of size 16 alloc'd
==16603==    at 0x4C2845D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16603==    by 0x56195E: sqlite3MemMalloc (sqlite3.c:16881)
==16603==    by 0x49694F: sqlite3Malloc (sqlite3.c:20509)
==16603==    by 0x497747: sqlite3DbMallocRaw (sqlite3.c:20906)
==16603==    by 0x58AED4: sqlite3AddDefaultValue (sqlite3.c:20991)
==16603==    by 0x7AC913: sqlite3Parser (sqlite3.c:123890)
==16603==    by 0x7BE668: sqlite3RunParser (sqlite3.c:125943)
==16603==    by 0x7C1129: sqlite3Prepare (sqlite3.c:105025)
==16603==    by 0x7C25D0: sqlite3LockAndPrepare.part.504 (sqlite3.c:105120)
==16603==    by 0x7C2C4F: sqlite3LockAndPrepare.constprop.573 (sqlite3.c:105115)
==16603==    by 0x7C34A4: sqlite3InitCallback (sqlite3.c:105184)
==16603==    by 0x757DD0: sqlite3_exec (sqlite3.c:100669)

Cheers,
/mz
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to