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

[PATCH] avoid possible overflow in delta size filtering computation

From
Nicolas Pitre <nico@cam.org>
Date
Mar 24, 2009, 19:56 UTC
Message-ID
<alpine.LFD.2.00.0903241535010.26337@xanadu.home>

On a 32-bit system, the maximum possible size for an object is less than 4GB, while 64-bit systems may cope with larger objects. Due to this limitation, variables holding object sizes are using an unsigned long type (32 bits on 32-bit systems, or 64 bits on 64-bit systems).

When large objects are encountered, and/or people play with large delta depth values, it is possible for the maximum allowed delta size computation to overflow, especially on a 32-bit system. When this occurs, surviving result bits may represent a value much smaller than what it is supposed to be, or even zero. This prevents some objects from being deltified although they do get deltified when a smaller depth limit is used. Fix this by always performing a 64-bit multiplication.

Signed-off-by: Nicolas Pitre <nico@cam.org>
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 3a4bdbb..9fc3b35 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1293,7 +1293,7 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
 		max_size = trg_entry->delta_size;
 		ref_depth = trg->depth;
 	}
-	max_size = max_size * (max_depth - src->depth) /
+	max_size = (uint64_t)max_size * (max_depth - src->depth) /
 						(max_depth - ref_depth + 1);
 	if (max_size == 0)
 		return 0;
Next: Brandon Casey
Message 1 of 10 in “avoid possible overflow in delta size filtering computation”
  1. avoid possible overflow in delta size filtering computationNicolas Pitre, Mar 24, 2009
  2. Brandon CaseyMar 24, 2009
  3. Nicolas PitreMar 24, 2009
  4. Nicolas PitreMar 25, 2009
  5. Kjetil BarvikMar 25, 2009
  6. Nicolas PitreMar 25, 2009
  7. Kjetil BarvikMar 25, 2009
  8. Nicolas PitreMar 25, 2009
  9. Kjetil BarvikMar 26, 2009
  10. Nicolas PitreMar 27, 2009

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.