]> git.99rst.org Git - git.git/commit
bisect: ensure non-NULL `head` before using it
authorJohannes Schindelin <redacted>
Fri, 10 Jul 2026 11:39:34 +0000 (11:39 +0000)
committerJunio C Hamano <redacted>
Fri, 10 Jul 2026 15:13:55 +0000 (08:13 -0700)
commit7384654acfa963512805ab0476602cbe8b0a2033
tree2fd6bb7128f420198eef2ae50a39939cf95eabe0
parent436ef7c1e4131c31ae1a9152261c2c67c7affa21
bisect: ensure non-NULL `head` before using it

When `refs_resolve_ref_unsafe()` is called to resolve HEAD, and returns
NULL (e.g., HEAD does not exist as a proper ref), the code falls back to
`repo_get_oid("HEAD")` to try to resolve the OID directly. If that
succeeds, execution continues with `head` still set to NULL.

Later, that variable is passed to `repo_get_oid()` and `starts_with()`,
both of which would dereference the NULL pointer.

A concrete trigger for `refs_resolve_ref_unsafe()` returning NULL while
`repo_get_oid()` succeeds could not be constructed against the ref
backends currently in the tree; the naive case (a symbolic HEAD pointing
at a nonexistent branch, in either the files or the reftable backend)
fails in both calls consistently and returns via the existing
`error(_("bad HEAD - I need a HEAD"))` path.  Coverity, however, flags
the leftover use of `head` after the outer `if (!head)` on a formal
reading: `head` is still NULL at that point, and both `starts_with(head,
...)` and the second `repo_get_oid(..., head, ...)` in the else-branch
would dereference it if that state were ever reached.

Removing the outer check would risk regressing to a crash if a future
ref backend ever manages to hit the "returns NULL for HEAD but has a
valid OID for HEAD" state.  Assigning the literal string "HEAD" as a
safe fallback documents the intent and satisfies the analyzer without
changing behavior in any code path we can currently reach.

Assisted-by: Claude Opus 4.7
Signed-off-by: Johannes Schindelin <redacted>
Signed-off-by: Junio C Hamano <redacted>
builtin/bisect.c
git clone https://git.99rst.org/PROJECT