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]

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](https://user-images.githubusercontent.com/87304478/131200799-b8340903-5d08-4f46-a65a-d4ed4b1f8c38.png)



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](https://user-images.githubusercontent.com/87304478/131200819-e385dd14-511c-48d8-aa34-1e13894271bf.png)



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](https://user-images.githubusercontent.com/87304478/131200832-24b0d30a-dd7a-4f6c-8e95-2216faecc491.png)



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](https://user-images.githubusercontent.com/87304478/131200847-56f89c71-c500-4878-8b71-4df738ce2d10.png)
![image](https://user-images.githubusercontent.com/87304478/131200862-f96fe6dc-325b-407a-b811-319b78dcf6ae.png)
![image](https://user-images.githubusercontent.com/87304478/131200867-007875c9-4084-4b4f-85ae-47800a728f37.png)
![image](https://user-images.githubusercontent.com/87304478/131200870-c84faead-b3d7-4118-9f80-955e0585e69d.png)
![image](https://user-images.githubusercontent.com/87304478/131200872-d51e6e85-05e9-4316-a5d2-730e7297f8bf.png)



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](https://user-images.githubusercontent.com/87304478/131200895-39a7f99f-e153-4399-ab7f-c8e775e20de7.png)


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](https://user-images.githubusercontent.com/87304478/131200905-6c1f47d2-1072-4208-882c-4583c1b74591.png)

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](https://user-images.githubusercontent.com/87304478/131200911-c6bb47f4-0ce6-41e0-a21e-6cdc0c6e2370.png)
![image](https://user-images.githubusercontent.com/87304478/131200915-3b0ae70d-0cb1-4f73-9a08-d7cf6890a506.png)


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](https://user-images.githubusercontent.com/87304478/131200925-daee0407-a58c-446e-a58e-e938299fb123.png)
![image](https://user-images.githubusercontent.com/87304478/131200930-846bac9d-2f96-4665-9531-9044168bbdbe.png)
![image](https://user-images.githubusercontent.com/87304478/131200946-0304b59f-abc2-4b06-b6d3-2c6befa6469e.png)

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

> 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

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]

It would be better to do it against the [trunk version](https://sqlite.org/src/). 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]

Deleted

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

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.

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

Please don't [edit an original posting](/forumpost/2976d71578?hist) 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]

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.

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

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>"