Segmentation Fault on query

(1.2) By Yu Liang (LY1598773890) on 2022-10-17 15:52:57 edited from 1.1 [source]

The latest version of SQLite3 crashes when executing the following queries:

CREATE TABLE t0(b);
.limit le 0;
EXPLAIN QUERY PLAN SELECT*FROM t0;

The stack backtrace is shown below:

#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1  0x0000000000438a8f in eqp_append (p=0x7fffffffcc10, iEqpId=0x2, p2=0x0, zText=0x0) at shell.c:13192
#2  0x000000000043784c in shell_callback (pArg=0x7fffffffcc10, nArg=0x4, azArg=0x6dba30, azCol=0x6dba10, aiType=0x6dba50) at shell.c:13700
#3  0x000000000043a0b6 in exec_prepared_stmt (pArg=0x7fffffffcc10, pStmt=0x6aaa00) at shell.c:14884
#4  0x0000000000418297 in shell_exec (pArg=0x7fffffffcc10, zSql=0x6d4400 "EXPLAIN QUERY PLAN SELECT * FROM t1 WHERE b=1;", pzErrMsg=0x7fffffffca00) at shell.c:15160
#5  0x000000000043e1af in runOneSqlLine (p=0x7fffffffcc10, zSql=0x6d4400 "EXPLAIN QUERY PLAN SELECT * FROM t1 WHERE b=1;", in=0x7ffff7d6d980 <_IO_2_1_stdin_>,
    startline=0x4a3) at shell.c:22767
#6  0x0000000000418f6d in process_input (p=0x7fffffffcc10) at shell.c:22931
#7  0x000000000040ac18 in main (argc=0x1, argv=0x7fffffffe238) at shell.c:23786
#8  0x00007ffff7ba5083 in __libc_start_main (main=0x408e40 <main>, argc=0x1, argv=0x7fffffffe238, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=0x7fffffffe228) at ../csu/libc-start.c:308
#9  0x000000000040377e in _start ()

When testing with UBSAN, the sanitizer reports the following error:

UndefinedBehaviorSanitizer:DEADLYSIGNAL
==1220264==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fcd78d6c6e5 bp 0x000000000004 sp 0x7ffd8b3d1488 T1220264)
==1220264==The signal is caused by a READ memory access.
==1220264==Hint: address points to the zero page.
    #0 0x7fcd78d6c6e5  /build/glibc-SzIz7B/glibc-2.31/string/../sysdeps/x86_64/multiarch/strlen-avx2.S:65
    #1 0x45dc51 in eqp_append /home/luy70/Desktop/sqlite_source_fossil/sqlite/shell.c:13192:15
    #2 0x45dc51 in shell_callback /home/luy70/Desktop/sqlite_source_fossil/sqlite/shell.c:13700:7
    #3 0x4620d3 in exec_prepared_stmt /home/luy70/Desktop/sqlite_source_fossil/sqlite/shell.c:14884:15
    #4 0x44333b in shell_exec /home/luy70/Desktop/sqlite_source_fossil/sqlite/shell.c:15160:7
    #5 0x46522f in runOneSqlLine /home/luy70/Desktop/sqlite_source_fossil/sqlite/shell.c:22767:8
    #6 0x4459c5 in process_input /home/luy70/Desktop/sqlite_source_fossil/sqlite/shell.c:22950:15
    #7 0x430b06 in main /home/luy70/Desktop/sqlite_source_fossil/sqlite/shell.c
    #8 0x7fcd78c08082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
    #9 0x406acd in _start (/home/luy70/Desktop/tmp/crashes_of_sqlite3/poc_1/sqlite3_inst+0x406acd)

The bug seems to trace back BEFORE Fossil Commit: c33a275bf1a0ea10 from 2015-11-02.

Thank you.

(2) By RandomCoder on 2022-10-17 16:07:13 in reply to 1.2 [link] [source]

For what its worth, this sequence doesn't crash before SQLite 3.39.0

(3) By Richard Hipp (drh) on 2022-10-17 16:17:27 in reply to 1.2 [link] [source]

CLI bug fixed on trunk. Thanks for the bug report, Yu.

Key details:

This is a bug in the CLI, not in the core SQLite library.
A call to strlen() with a NULL pointer might be made following an out-of-memory error, or an attempt to allocate a string buffer longer than the maximum allowed string.
This is not an RCE attack nor a data exfiltration attack because the result is always a segfault.
This is not a problem that an attacker can reasonably exploit, because to cause the problem you must have shell access already, and if the attacker already has shell access, this bug does nothing to give the attacker any additional power or privilege.

(4) By Yu Liang (LY1598773890) on 2022-10-17 17:24:45 in reply to 3 [link] [source]

Thank you Richard for the very quick fix and response!

(5) By anonymous on 2022-10-17 18:04:05 in reply to 3 [link] [source]

Is it not better/safer to replace this fix by sqlite3Strlen30() ?