SQLite Forum

SQLite Heap overflow

SQLite Heap overflow

(1) By anonymous on 2021-03-29 20:19:13 [link] [source]

There is a double free caused by a certain "sqlite3GlobalConfig.m.xFree(p); sqlite3_mutex_leave(mem0.mutex); } else { sqlite3GlobalConfig.m.xFree(p);" code block.

here is a CVE associated with this. Use CVE-2021-28491.

(2) By Larry Brasfield (larrybr) on 2021-03-29 20:34:27 in reply to 1 [link] [source]

Why are you reporting this here? The CVE clearly attributes the problem to an application which uses the SQLite library and happens to over-use sqlite3_free(). Are you suggesting that the library should somehow detect such usage? (Not likely to happen.)

(3.1) By Keith Medcalf (kmedcalf) on 2021-03-29 22:05:02 edited from 3.0 in reply to 2 [link] [source]

How do you find this? The only information I can find says "This is reserved but zero details have yet been provided". HOwever, I do not permit rampant unauthorized or unknown code to execute on my computer, so maybe the NVD requires the ability for unfettered third-party code execution to work (which is a major security risk in itself and would lead me to the conclusion that the whole kaboodle is a preposterous POS designed by lunatics).

(4) By Larry Brasfield (larrybr) on 2021-03-29 22:48:51 in reply to 3.1 [link] [source]

A web search got me to https://nvd.nist.gov/vuln/detail/CVE-2020-28491 , where there is not much but enough to call it an application problem. I also looked at the code quoted in post 1, which is in sqlite3_free(), just as it passes control into the runtime-switchable allocator implementation. I am pretty sure that duplicate freeing is not a library problem, and showing that sqlite3_free() was in a callstack (I presume) is extremely weak evidence upon which to claim otherwise.

As for rampant mystery code, I too am careful to avoid running such. But I did not have to do that to legitimately wonder why the OP posts this CVE here. If there is some evidence implicating the library, it's worth digging out, IMO.

(5) By Keith Medcalf (kmedcalf) on 2021-03-29 22:57:19 in reply to 4 [source]

You will note that is a DIFFERENT CVE.

The OP posted about CVE-2021-28491, not CVE-2020-28491.

Note that the YEAR is different.

I have found no reference anywhere to CVE-2021-28491 other than saying that it may have been issued and may be reserved but that no details are available.

(6.2) By Larry Brasfield (larrybr) on 2021-03-29 23:35:38 edited from 6.1 in reply to 5 [link] [source]

Well, I'm batting low on the infallibility scale today. Those middle digits are too easy to skim over on a sleep deficit.

I still maintain that getting sqlite3_free to show up in a callstack is extremely weak evidence for attributing a duplicate free problem to SQLite. It's like blaming car bumpers for pedestrian-versus-car casualties.

(Added via edit for clarity:) Here is pseudo-code for the routine very weakly implicated in post #1: SQLITE_API void sqlite3_free(void *p){ /* Error checks, early exit on NULL, and mutex wrapping omitted */ PlatformSpecificOrClientSelectedAllocatorMethods.free(p); } . To the accusation that the inner .free did a duplicate free, the defense is: The sqlite3_free() caller did a duplicate free. As to whether the SQLite library called its own free too much or the library client did, no clues are yet in evidence.