db-5.3.28/src/heap/heap_verify.c has code of the structure:
__heap_vrfy(dbp, vdp, h, pgno, flags)
int cnt, i, j, ret;
db_indx_t *offsets, *offtbl, end;
if ((ret = __db_vrfy_datapage(dbp, vdp, h, pgno, flags)) != 0)
. . .
err: __os_free(dbp->env, offsets);
If the listed goto is executed then __os_free is passed an uninitialized offsets value (a junk pointer).
This was reported by the compiler used to build databases/db5.
What do you propose we do about this?
(In reply to Matthias Andree from comment #1)
I was not directly trying to build db5. It just showed up via dependencies. So I'm not familiar with it at all.
Since bad pointers and freeing them tend to be security risks as well as just wrong so I'd hope for changes to avoid the bad (uninitialized) pointer use.
Looking at db-5.3.28/src/os/os_alloc.c and its __os_free(. . .) implementation (found via grep) indicates that the such is an issue here:
. . .
if (DB_GLOBAL(j_free) != NULL)
I will not show the whole routine here but all code paths require ptr to have a valid pointer value for testing and/or use.
My quick estimate would be that the specific "goto err" that I originally showed should instead be "return ret;" (or "return (ret);" in the style of the existing code).
If you have upstream contacts it would seem appropriate to propagate the information upstream (where ever that is).
The build was of db5-5.3.28_4 --which is still in place as of /usr/ports/ -r419343 .
A commit references this bug:
Date: Wed Nov 9 22:31:49 UTC 2016
New revision: 425813
Avoid junk pointer when __db_vrfy_datapage() fails
Rather than second-guessing what the __os_free() might be doing and
avoiding it, initialize the pointer to NULL, which __os_free() will
skip. This should be the safer approach if Oracle ever patches other
parts of db 5.3.
Submitted by: Mark Millard
I don't have upstream contacts, nor have I found a bug report address on Oracle's website that wouldn't require logins or contracts. If I've missed one, drop me a heads-up or someone file this with Oracle and add a comment to this PR.
The commit accidentally bumped files/patch-lang_tcl_tcl__env.c and files/patch-lang_tcl_tcl__seq.c. These changes only affected patch/diff timestamps but not content.