SQLite Forum

several potential bugs of null pointer dereference
Login

several potential bugs of null pointer dereference

(1) By hyx (hyxl1017) on 2021-08-28 00:54:43 [link] [source]

sqlite version:3.22

Hello,I found some potential bugs of null pointer dereference in sqlite3.Would you help me check whether the bugs mentioned below are true? Thank you very much for your patience.

In file sqlite3/build/sqlite3.c(build is a folder contain files generated by configure) In function sqlite3VtabCallDestroy In line 128391.There is a statement load return value of function vtabDisconnectedAll to pointer p and return value can be null. In line 128392.There is a statment derefer p without check. image

In sqlite3-3.22.0/src/tclsqlite.c In function dbReleaseStmt In line 1421: pointer pPrev is initilized to null,and in a certain path,the value of pPrev not be changed and derefered without check. image

In file sqlite3/build/sqlite3.c(build is a folder contain files generated by configure) In function vdbeSorterFlushPMA In line 89710,pointer pTask is derefered without check and its value can be null. image

In file sqlite3/build/sqlite3.c(build is a folder contain files generated by configure) In function sqlite3CodeRowTriggerDirect In line 126110: pointer v load return value of function sqliteGetVdbe and its value can be null. In line 126120: pointer v act as the 1st parameter of function sqlite3VdbeAddOp4 and in this function,v will derefer without check. image image image image image

In file sqlite3/build/sqlite3.c(build is a folder contain files generated by configure) In function sqlite3_randomness In line 27774:return value of sqlite3_vfs_find which can be null act as the 1st parameter of function sqlite3OsRandomness,in this function,return value of sqlite3_vfs_find is derefered without check. image

In file sqlite3/build/shell.c(build is a folder contain files generated by configure) In function process_input In line 14653: zSql is initialized to null and in certain path,the value of zSql not be changed and derefered without check. image

In file sqlite3/build/shell.c(build is a folder contain files generated by configure) In function sqlite3_appendvfs_init In line 3949: return value of function sqlite3_vfs_fund which can be null is loaded to pOrig In line 3950: pOrig is derefered without check image image

In file sqlite3/build/sqlite3.c(build is a folder contain files generated by configure) In function fts3IncrmergeChomp In line 163794: pSeg is initialized to null. In line 163803: pSeg is derefered without check image image image

(2) By Richard Hipp (drh) on 2021-08-28 01:15:37 in reply to 1 [source]

Would you help me check whether the bugs mentioned below are true?

No. Reasons:

  1. You are referencing version 3.22.0 which is now over 3.5 years old. The latest release is 3.36.0.

  2. Static analyzers are usually wrong about this stuff.

(3) By hyx (hyxl1017) on 2021-08-31 04:04:38 in reply to 2 [link] [source]

ok,I will check if these bugs exist in latest release.

(4) By Warren Young (wyoung) on 2021-08-31 11:48:48 in reply to 3 [link] [source]

It would be better to do it against the trunk version. Not only does that eliminate the gap between the last release and the current development version, it gives you the pre-amalgamation source files to work on, which will make your tool’s line references more useful.

(5.2) By J.M. Aranda (JMAranda) on 2021-09-01 12:35:23 edited from 5.1 in reply to 3 [link] [source]

Deleted

(6) By Warren Young (wyoung) on 2021-08-31 12:43:18 in reply to 5.0 [link] [source]

It's a big step from "Static analyzers are usually wrong" to "They are not bugs." This particular static analyzer may be right in one or more of these cases, but proof requires more than some bold red text on a PNG.

I believe this report wouldn't have been immediately disregarded and so would have received a less dismissive reply if the many problems in the original report were fixed:

  • We knew this "hyx" user by reputation, from prior posting.
  • He made the reports against the trunk version.
  • The line numbers were against the actual src/*.c files, not against the amalgamation.
  • The reports were in plain text — possibly with Markup formatting — rather than bitmapped-images-of-text.
  • Each flagged case was accompanied by separate prose descriptions of the reporter's hypothesis justifying the report. (Or, better, included proof-of-concept code showing how to exploit the claimed flaws.)

I'm with drh on this one: this "hyx" user has shown little regard for what the developers need and care about when going after static analyzer reports.

One more thing: knowing which tool gave this output might be helpful, too, particularly if it's available to drh, so he could just run it himself. If it's somehow proprietary, then we don't know what the tool is doing, so we can't evaluate how useful it is. Just because some bit of dumb anonymous software gave a report about some other bit of software doesn't justify work chasing the resulting output.

(9) By anonymous on 2021-09-03 20:35:54 in reply to 6 [link] [source]

This same person, Hyxl1017, seems to be doing this to a variety of projects: claiming some static analyzer has found null pointer bugs in some very old version of the software.

Things that make you go "hmmmm>"

(7) By Warren Young (wyoung) on 2021-08-31 14:06:42 in reply to 5.1 [link] [source]

Please don't edit an original posting to change its meaning when it has replies referring to that original meaning. Reply to the reply if you wish to back off on some position you previously took.

(8) By J.M. Aranda (JMAranda) on 2021-09-01 12:44:45 in reply to 7 [link] [source]

The formal verification of a system requires defining a context, some axioms. Download a free program and use it without more on SQLite, in case you find a bug and report it, I think it is not serious.