path: root/t/
diff options
authorJeff King <>2017-04-01 08:05:21 (GMT)
committerJunio C Hamano <>2017-04-01 17:45:16 (GMT)
commit93cff9a978e1c177ac3e889867004a56773301b2 (patch)
tree04d51c6baf53266ac783cfa0a4ef52d58a95a058 /t/
parent49800c940790cc7465d1b03e08d472ffd8684808 (diff)
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 <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 't/')
1 files changed, 7 insertions, 0 deletions
diff --git a/t/ b/t/
index 3f87051..3a88d79 100755
--- a/t/
+++ b/t/
@@ -53,6 +53,13 @@ test_expect_success 'streaming a corrupt blob fails' '
+test_expect_success 'getting type of a corrupt blob fails' '
+ (
+ cd bit-error &&
+ test_must_fail git cat-file -s HEAD:content.t
+ )
test_expect_success 'read-tree -u detects bit-errors in blobs' '
cd bit-error &&