NULL pointer access in sqlite3MemdbInit
(1) By kjarvel on 2021-04-12 14:04:56 [source]
I'm building the sqlite3.c
amalgamation version 3.35.4, for an embedded system without an OS, with these defines:
SQLITE_OS_OTHER
SQLITE_ENABLE_DESERIALIZE
The problem can be reproduced with with Visual C++ in Windows.
The build is OK, but at sqlite3_open(":memory:", &db)
, there is a NULL pointer access in sqlite3MemdbInit
:
SQLITE_PRIVATE int sqlite3MemdbInit(void){
sqlite3_vfs *pLower = sqlite3_vfs_find(0);
int sz = pLower->szOsFile;
Since sqlite3_vfs_register
has not been called at this point, pLower
is NULL,
and pLower->szOsFile
is not valid.
(sqlite3_vfs_register(&memdb_vfs,0)
is called a few lines later).
Suggested change, to handle the NULL pointer:
int sz = pLower ? pLower->szOsFile : 0;
A similar problem is in memdbRandomness
:
static int memdbRandomness(sqlite3_vfs *pVfs, int nByte, char *zBufOut){
return ORIGVFS(pVfs)->xRandomness(ORIGVFS(pVfs), nByte, zBufOut);
ORIGVFS(pVfs)
is the pAppData
pointer in memdb_vfs
, which is 0x0.
Suggested change, to handle the NULL pointer:
return ORIGVFS(pVfs) ? ORIGVFS(pVfs)->xRandomness(ORIGVFS(pVfs), nByte, zBufOut) : 0;
After this, it works fine.
Sorry if I misunderstood or mis-used sqlite3.c in some way, maybe there is another/real solution? Thank you!
(2) By David Boden (davidboden) on 2023-01-01 16:35:17 in reply to 1 [link] [source]
Happy New Year. I notice that this issue has also been mentioned in post: https://sqlite.org/forum/forumpost/48d46020bbbe5703a4805383e8d459ee6e689a73a5f7272ad9c2266b0c1eba10
I'm new to embedded programming and using SQLite in that environment. It would be great if we could build SQLite with SQLITE_OS_OTHER and then open up a ":memory:" database without having to worry about setting up a VFS at all. I think it would make a good test case, which would currently fail due to the issues you've mentioned if no steps have been taken to register a VFS.
Perhaps there are some additional tasks carried out by the VFS, such as finding a source of randomness, that means there's a need for a VFS even for in-memory databases? Would appreciate some feedback from an experienced SQLite developer as to whether it's realistic to expect creating in-memory databases to be easy within SQLITE_OS_OTHER builds.
(3) By Stephan Beal (stephan) on 2023-01-01 16:52:44 in reply to 2 [link] [source]
Would appreciate some feedback from an experienced SQLite developer as to whether it's realistic to expect creating in-memory databases to be easy within SQLITE_OS_OTHER builds.
The short answer is no. The memdb VFS inherits functionality from whichever VFS is built in as the default, so requires another VFS to be built in.