git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 1/2] sha1_loose_object_info: return error for corrupted objects

From
Jeff King <peff@peff.net>
Date
Apr 1, 2017, 08:05 UTC
Message-ID
<20170401080521.ehjc6jomjd5py3lj@sigill.intra.peff.net>
In-Reply-To
<20170401080349.lccextuc3l6fgs6j@sigill.intra.peff.net>

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>
---
So not only does it not fail, but running with --valgrind complains.
 sha1_file.c                  | 2 +-
 t/t1060-object-corruption.sh | 7 +++++++
 2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index 71063890f..368c89b5c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2952,7 +2952,7 @@ static int sha1_loose_object_info(const unsigned char *sha1,
 	if (status && oi->typep)
 		*oi->typep = status;
 	strbuf_release(&hdrbuf);
-	return 0;
+	return (status < 0) ? status : 0;
 }
 
 int sha1_object_info_extended(const unsigned char *sha1, struct object_info *oi, unsigned flags)
diff --git a/t/t1060-object-corruption.sh b/t/t1060-object-corruption.sh
index 3f8705139..3a88d79c5 100755
--- a/t/t1060-object-corruption.sh
+++ b/t/t1060-object-corruption.sh
@@ -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 &&
-- 
2.12.2.943.g91cb50fd8
Previous: Jeff KingNext: Junio C Hamano
Message 10 of 15 in “SHA1 collision in production repo?! (probably not)”
  1. Lars SchneiderMar 31, 2017
  2. Jeff KingMar 31, 2017
  3. Junio C HamanoMar 31, 2017
  4. Jeff KingMar 31, 2017
  5. Jeff KingMar 31, 2017
  6. Junio C HamanoMar 31, 2017
  7. Jeff KingMar 31, 2017
  8. Junio C HamanoMar 31, 2017
  9. Jeff KingApr 1, 2017
  10. 1/2 sha1_loose_object_info: return error for corrupted objectsJeff King, Apr 1, 2017
  11. Junio C HamanoApr 1, 2017
  12. 2/2 index-pack: detect local corruption in collision checkJeff King, Apr 1, 2017
  13. Junio C HamanoApr 1, 2017
  14. Lars SchneiderSep 12, 2017
  15. Jeff KingSep 12, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.