diff options
author | Jeff King <peff@peff.net> | 2017-04-01 04:05:21 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2017-04-01 10:45:16 -0700 |
commit | 93cff9a978e1c177ac3e889867004a56773301b2 (patch) | |
tree | 04d51c6baf53266ac783cfa0a4ef52d58a95a058 /t/t4018/custom1-pattern | |
parent | Prepare for 2.12.3 (diff) | |
download | tgif-93cff9a978e1c177ac3e889867004a56773301b2.tar.xz |
sha1_loose_object_info: return error for corrupted objects
When sha1_loose_object_info() finds that a loose object file
cannot be stat(2)ed or mmap(2)ed, it returns -1 to signal an
error to the caller. However, if it found that the loose
object file is corrupt and the object data cannot be used
from it, it stuffs OBJ_BAD into "type" field of the
object_info, but returns zero (i.e., success), which can
confuse callers.
This is due to 052fe5eac (sha1_loose_object_info: make type
lookup optional, 2013-07-12), which switched the return to a
strict success/error, rather than returning the type (but
botched the return).
Callers of regular sha1_object_info() don't notice the
difference, as that function returns the type (which is
OBJ_BAD in this case). However, direct callers of
sha1_object_info_extended() see the function return success,
but without setting any meaningful values in the object_info
struct, leading them to access potentially uninitialized
memory.
The easiest way to see the bug is via "cat-file -s", which
will happily ignore the corruption and report whatever
value happened to be in the "size" variable.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t4018/custom1-pattern')
0 files changed, 0 insertions, 0 deletions