ewah_read_mmap: bounds-check mmap reads
commit9d2e330b1795222c2c816afa46138e7ff4ebec8e
authorJeff King <peff@peff.net>
Fri, 15 Jun 2018 03:31:13 +0000 (14 23:31 -0400)
committerJunio C Hamano <gitster@pobox.com>
Mon, 18 Jun 2018 16:13:57 +0000 (18 09:13 -0700)
tree615745f2611f52e42bf28137ab9594fd773a3523
parenta42a58d7b62cc1d6301440e81a83feed9d7c118c
ewah_read_mmap: bounds-check mmap reads

The on-disk ewah format tells us how big the ewah data is,
and we blindly read that much from the buffer without
considering whether the mmap'd data is long enough, which
can lead to out-of-bound reads.

Let's make sure we have data available before reading it,
both for the ewah header/footer as well as for the bit data
itself. In particular:

  - keep our ptr/len pair in sync as we move through the
    buffer, and check it before each read

  - check the size for integer overflow (this should be
    impossible on 64-bit, as the size is given as a 32-bit
    count of 8-byte words, but is possible on a 32-bit
    system)

  - return the number of bytes read as an ssize_t instead of
    an int, again to prevent integer overflow

  - compute the return value using a pointer difference;
    this should yield the same result as the existing code,
    but makes it more obvious that we got our computations
    right

The included test is far from comprehensive, as it just
picks a static point at which to truncate the generated
bitmap. But in practice this will hit in the middle of an
ewah and make sure we're at least exercising this code.

Reported-by: Luat Nguyen <root@l4w.io>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ewah/ewah_io.c
ewah/ewok.h
t/t5310-pack-bitmaps.sh