SQLCipher segfaults on sqlite3_key(NULL, NULL, 0) with v4.7.0+, but did not segfault on v4.6.1 #578
Description
On Debian systems, for the following minimal program:
#include <stdio.h>
#include "/usr/include/sqlcipher/sqlite3.h"
//extern int sqlite3_key(sqlite3 *db, const void *pKey, int nKey);
int main(void)
{
printf("Calling sqlite3_key(NULL, NULL, 0)...\n");
int rc = sqlite3_key(NULL, NULL, 0);
printf("Return code: %d\n", rc);
return 0;
}We build it from source using gcc test_key_null.c -o test_key_null $(pkg-config --cflags --libs sqlcipher) -I/usr/include -DSQLITE_HAS_CODEC:
When building with sqlcipher 4.6.1:
-> % ./test_key_null
Calling sqlite3_key(NULL, NULL, 0)...
Return code: 1
When building with sqlcipher 4.11.0:
-> % ./test_key_null
Calling sqlite3_key(NULL, NULL, 0)...
[1] 2190 segmentation fault ./test_key_null
Looks like it was caused by 291dc9b . I wonder whether this behaviour is a regression or intentional.
You may argue that this usage is completely wrong, but it exists in real projects. For example, in KDE's KMyMoney v5.2.1 release:
- https://invent.kde.org/office/kmymoney/-/blob/c3d3f7e5d36d76b4e456de6a88e1ac048dd62792/kmymoney/kmymoney.cpp#L1028-1046
- Downstream bug report: https://bugs.kde.org/show_bug.cgi?id=512485
Maybe it will be better to add a guard check in sqlite3_key_v2() function to fail early when db is NULL, instead of plain segfaults directly in sqlcipher_find_db_index(). For example, something like:
if (db == NULL) {
return SQLITE_MISUSE;
}