]> git.ipfire.org Git - thirdparty/git.git/commit - t/t5303-pack-corruption-resilience.sh
sha1_file: Fix infinite loop when pack is corrupted
authorShawn O. Pearce <spearce@spearce.org>
Wed, 14 Oct 2009 14:23:51 +0000 (07:23 -0700)
committerJunio C Hamano <gitster@pobox.com>
Wed, 14 Oct 2009 20:39:37 +0000 (13:39 -0700)
commitb3118bdc91876cbc04b7e81dcf7bea71d86ce4f8
treeaa1b183bcec0f4057addaad2ad5f437e13540622
parent583371af1f88e9cd48fedbb6bbb147d8091fd591
sha1_file: Fix infinite loop when pack is corrupted

Some types of corruption to a pack may confuse the deflate stream
which stores an object.  In Andy's reported case a 36 byte region
of the pack was overwritten, leading to what appeared to be a valid
deflate stream that was trying to produce a result larger than our
allocated output buffer could accept.

Z_BUF_ERROR is returned from inflate() if either the input buffer
needs more input bytes, or the output buffer has run out of space.
Previously we only considered the former case, as it meant we needed
to move the stream's input buffer to the next window in the pack.

We now abort the loop if inflate() returns Z_BUF_ERROR without
consuming the entire input buffer it was given, or has filled
the entire output buffer but has not yet returned Z_STREAM_END.
Either state is a clear indicator that this loop is not working
as expected, and should not continue.

This problem cannot occur with loose objects as we open the entire
loose object as a single buffer and treat Z_BUF_ERROR as an error.

Reported-by: Andy Isaacson <adi@hexapodia.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sha1_file.c
t/t5303-pack-corruption-resilience.sh