db-5.3.28/src/heap/heap_verify.c has code of the structure: int __heap_vrfy(dbp, vdp, h, pgno, flags) DB *dbp; VRFY_DBINFO *vdp; PAGE *h; db_pgno_t pgno; u_int32_t flags; { HEAPHDR *hdr; int cnt, i, j, ret; db_indx_t *offsets, *offtbl, end; if ((ret = __db_vrfy_datapage(dbp, vdp, h, pgno, flags)) != 0) goto err; . . . err: __os_free(dbp->env, offsets); return (ret); } 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: void __os_free(env, ptr) ENV *env; void *ptr; { . . . if (DB_GLOBAL(j_free) != NULL) DB_GLOBAL(j_free)(ptr); else free(ptr); } 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: Author: mandree Date: Wed Nov 9 22:31:49 UTC 2016 New revision: 425813 URL: https://svnweb.freebsd.org/changeset/ports/425813 Log: 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. PR: 210829 Submitted by: Mark Millard Changes: head/databases/db5/Makefile head/databases/db5/files/patch-lang_tcl_tcl__env.c head/databases/db5/files/patch-lang_tcl_tcl__seq.c head/databases/db5/files/patch-src_heap_heap__verify.c
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.