On Thu, Jan 30, 2014 at 4:50 PM, Jeff King <[email protected]> wrote:
> I think we could do this with something like the patch below, which
> checks two things:
>
> 1. When we expand the ewah, it has the same number of bits we claimed
> in the on-disk header.
>
> 2. The ewah header matches the number of objects in the packfile.
>
> The first catches a corruption in the ewah data itself, and the latter
> when the header is corrupted. You can test either by breaking the
> endian-swapping. :)
>
> diff --git a/pack-bitmap.c b/pack-bitmap.c
> index ae0b57b..a31e529 100644
> --- a/pack-bitmap.c
> +++ b/pack-bitmap.c
> @@ -130,6 +131,31 @@ static struct ewah_bitmap *read_bitmap_1(struct
> bitmap_index *index)
> return NULL;
> }
>
> + /*
> + * It's OK for us to have too fewer bits than objects, as the EWAH
s/fewer/few/
> + * writer may have simply left off an ending that is all-zeroes.
> + *
> + * However it's not OK for us to have too many bits, as that would
> + * entail touching objects that we don't have. We are careful
> + * enough to avoid doing so in later code, but in the case of
> + * nonsensical values, we would want to avoid even allocating
> + * memory to hold the expanded bitmap.
> + *
> + * There is one exception: we may "go over" to round up to the next
> + * 64-bit ewah word, since the storage comes in chunks of that size.
> + */
> + expected_bits = index->pack->num_objects;
> + if (expected_bits & 63) {
> + expected_bits &= ~63;
> + expected_bits += 64;
> + }
> + if (b->bit_size > expected_bits) {
> + error("unexpected number of bits in bitmap: %"PRIuMAX" >
> %"PRIuMAX,
> + (uintmax_t)b->bit_size, (uintmax_t)expected_bits);
> + ewah_pool_free(b);
> + return NULL;
> + }
> +
> index->map_pos += bitmap_size;
> return b;
> }
> --
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
