SQLite User Forum

a SQL plain text discoverd by fuzzer causes SEGV
Login
Chronological

a SQL plain text discoverd by fuzzer causes SEGV

(1) By Jingzhou Fu (fuboat) on 2021-12-30 00:20:10 [source]

  • command: sqlite3 < crash.sql
  • version: 3.37.0
  • compile params: Clang-12 with ASAN (SEGV can also be triggered without ASAN)

PoC (crash.sql):

CREATE TABLE t1 ( c INTEGER PRIMARY KEY ON CONFLICT REPLACE , b TEXT , a UNIQUE ) ;
 INSERT INTO t1(b) VALUES(1);
 CREATE TRIGGER c0 AFTER UPDATE  ON t1 BEGIN
     INSERT INTO t1 VALUES(new.c, new.b, new.a)
         ON CONFLICT (a) DO NOTHING;
     END;
 UPDATE t1 SET b = 0;

gdb backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000000008d18cb in sqlite3VdbeExec (p=<optimized out>) at sqlite3.c:92862
92862     rc = sqlite3BtreeInsert(pC->uc.pCursor, &x,
(gdb) bt
#0  0x00000000008d18cb in sqlite3VdbeExec (p=<optimized out>) at sqlite3.c:92862
#1  0x00000000008807c8 in sqlite3_step (pStmt=<optimized out>) at sqlite3.c:85264
#2  0x00000000004108a5 in exec_prepared_stmt (pArg=0x7ffe7dedb9c0, pStmt=<optimized out>) at shell.c:14423
#3  0x00000000004099cd in shell_exec (pArg=<optimized out>, zSql=0x610000000140 "UPDATE t1 SET b = 0;", pzErrMsg=<optimized out>) at shell.c:14738
#4  0x000000000043ceb8 in runOneSqlLine (p=<optimized out>, zSql=<optimized out>, in=<optimized out>, startline=<optimized out>) at shell.c:21956
#5  0x00000000003cb368 in process_input (p=0x7ffe7dedb9c0) at shell.c:22066
#6  0x00000000003c1895 in main (argc=<optimized out>, argv=<optimized out>) at shell.c:22890

Maybe it is a bug?

(2) By RandomCoder on 2021-12-30 00:45:22 in reply to 1 [link] [source]

In case it helps anyone track down the issue: Up till 3.23.0 this generated a syntax error, then up till 3.34.1, it worked, and from 3.35.0 on, it crashes similar to as shown.

(3) By Richard Hipp (drh) on 2021-12-30 01:26:47 in reply to 2 [link] [source]

The problem bisects to https://www.sqlite.org/src/info/6b01a24daab1e5bc

(4) By Richard Hipp (drh) on 2021-12-30 03:00:52 in reply to 1 [link] [source]

Yes, this is a bug. Thank you for the clear and concise bug report.

The problem is that incorrect byte-code was being generated for a INSERT into a table that has an INTEGER PRIMARY KEY ON CONFLICT REPLACE and where there is also an ON CONFLICT clause on the INSERT that applies to some constraint other than the INTEGER PRIMARY KEY. When the incorrect byte-code is run, an assertion-fault or a NULL-pointer dereference might occur.

The problem was introduced by check-in 6b01a24daab1e5bc from about one year ago. That check-in enhanced the upsert capabilities.

A preliminary fix has been checked in at check-in 2f09b51b1ff37bf9. The actual fix is the single new line of code at line 2010 of the insert.c source file. The other changes shown in that check-in are for testing and validation only.