]> git.ipfire.org Git - thirdparty/git.git/commitdiff
pack-bitmap: handle missing bitmap for base MIDX
authorJohannes Schindelin <johannes.schindelin@gmx.de>
Fri, 10 Jul 2026 11:39:33 +0000 (11:39 +0000)
committerJunio C Hamano <gitster@pobox.com>
Fri, 10 Jul 2026 15:13:55 +0000 (08:13 -0700)
When `prepare_midx_bitmap_git()` is called to load the bitmap for a
chained MIDX's base layer, if the base MIDX does not have an associated
bitmap file (e.g., it was not generated, or was deleted by gc), the
return value is NULL. It is then stored in `bitmap_git->base` and
immediately dereferenced on the next line.

This can happen in practice with incremental MIDX chains: the base MIDX
may have been written without `--write-bitmap-index`, or the bitmap may
have been pruned while the incremental layer's bitmap still references
it.

Check the return value and go to the cleanup label (which unmaps the
current bitmap and returns -1) so the caller falls back to non-bitmap
object enumeration, matching the handling of other bitmap loading
failures in the same function.

Pointed out by Coverity.

Assisted-by: Claude Opus 4.6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pack-bitmap.c

index 83eb47a28ba9de44dfce1f52f5cca130c2552f98..0552c5fbec1bd635b5f016aded55eda735e06d72 100644 (file)
@@ -523,6 +523,10 @@ static int open_midx_bitmap_1(struct bitmap_index *bitmap_git,
 
        if (midx->base_midx) {
                bitmap_git->base = prepare_midx_bitmap_git(midx->base_midx);
+               if (!bitmap_git->base) {
+                       warning(_("could not open bitmap for base MIDX"));
+                       goto cleanup;
+               }
                bitmap_git->base_nr = bitmap_git->base->base_nr + 1;
        } else {
                bitmap_git->base_nr = 0;