aboutsummaryrefslogtreecommitdiffstats
path: root/commit.c
diff options
context:
space:
mode:
authorTaylor Blau <me@ttaylorr.com>2023-07-12 19:37:57 -0400
committerJunio C Hamano <gitster@pobox.com>2023-07-14 09:32:03 -0700
commit209250ef38f353f174ee9e90e55f5a4605449f70 (patch)
tree20184dea98066894f2b8eae9d2eda2922d887397 /commit.c
parentcommit-graph.c: prevent overflow in `write_commit_graph_file()` (diff)
downloadgit-209250ef38f353f174ee9e90e55f5a4605449f70.tar.gz
git-209250ef38f353f174ee9e90e55f5a4605449f70.zip
commit-graph.c: prevent overflow in add_graph_to_chain()
The commit-graph uses a fanout table with 4-byte entries to store the number of commits at each shard of the commit-graph. So it is OK to have a commit graph with as many as 2^32-1 stored commits. But we risk overflowing any computation which may exceed the 32-bit (unsigned) maximum when those computations are (incorrectly) performed using 32-bit operands. There are a couple of spots in `add_graph_to_chain()` where we could potentially overflow the result: - First, when comparing the list of existing entries in the commit-graph chain. It is unlikely that this should ever overflow, since it would require having roughly 2^32-1/g->hash_len commit-graphs in the chain. But let's guard that computation with a `st_mult()` just to be safe. - Second, when computing the number of commits in the graph added to the front of the chain. This value is also a 32-bit unsigned, but we should make sure that it does not grow beyond the maximum value. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'commit.c')
0 files changed, 0 insertions, 0 deletions