Re: [PATCH 1/1] midx.c: fix an integer overflow

From: Jeff King <peff@peff.net>
Date: Feb 28, 2020, 18:55 UTC
Message-ID: <20200228185525.GB1408759@coredump.intra.peff.net>
In-Reply-To: <20200228162450.1720795-1-damien.olivier.robert+git@gmail.com>

On Fri, Feb 28, 2020 at 05:24:49PM +0100, Damien Robert wrote:

Show 5 quoted lines

> When verifying a midx index with 0 objects, the
>     m->num_objects - 1
> overflows to 4294967295.
> 
> Fix this.

Makes sense. Such a midx shouldn't be generated in the first place, but we should handle it robustly if we do see one.

Show 13 quoted lines

> diff --git a/midx.c b/midx.c
> index 37ec28623a..6ffe013089 100644
> --- a/midx.c
> +++ b/midx.c
> @@ -1127,7 +1127,7 @@ int verify_midx_file(struct repository *r, const char *object_dir, unsigned flag
>  	if (flags & MIDX_PROGRESS)
>  		progress = start_sparse_progress(_("Verifying OID order in multi-pack-index"),
>  						 m->num_objects - 1);
> -	for (i = 0; i < m->num_objects - 1; i++) {
> +	for (i = 0; i + 1 < m->num_objects; i++) {
>  		struct object_id oid1, oid2;
>  
>  		nth_midxed_object_oid(&oid1, m, i);

[...]           nth_midxed_object_oid(&oid2, m, i + 1);

Perhaps it would be simpler as:

  for (i = 1; i < m->num_objects; i++) {
          ...
	  nth_midxed_object_oid(&oid1, m, i - 1);
	  nth_midxed_object_oid(&oid2, m, i);
	  ...
  }

Though I almost wonder if we should be catching "m->num_objects == 0" early and declaring the midx to be bogus (it's not _technically_ wrong, but I'd have to suspect a bug in anything that generated a 0-object midx file).

-Peff