Not a UAF; Not a vulnerability; Not a bug.

Check-in https://sqlite.org/src/info/4892440b93306e5a addresses the false positive. Using the line numbers on that check-in, the "pTab->nTabRef++" on line 612 prevents pTab->zName from being freed, unless there is an error, but if there is an error then code never reached lines 638 where the alleged UAF occurs. So the UAF is not possible and this is not a bug.

Nevertheless, your observation that we could use zModuleName in place of pTab->zName seems to be correct, so I went ahead and made that change to help out your static analyzer.

I also added two new assert() statements to help prove that the reference counter on pTab will not drop below one, and hence pTab->zName will not be freed, unless there is an error.

Note also that line 638 that contains the alleged UAF only executes if the application uses sqlite3_create_module() with a virtual table implementation that contains a bug: specifically one where sqlite3_declare_vtab() is never called by the xCreate or xConnect method of the sqlite3_module object. So there is no way to reach that line of code using SQL inputs and/or a corrupt database file - you must be able to link in a buggy extension. But if you can do that, you app is already pwned and it doesn't matter. So even if this had been a UAF, it would not have been a vulnerability.

Thanks for the report.

I assume the caveat about failing to call sqlite3_declare_vtab() in xCreate/xConnect only applies if it return SQLITE_OK. I have virtual tables that return SQLITE_ERROR (and set pzErr) if the input arguments for creating the table are invalid.

Correct. xCreate/xConnect are only required to call sqlite3_declare_vtab() if they return SQLITE_OK.

Thank you very much.