apply: detect overflow when parsing hunk header

From: Phillip Wood <[email protected]>

"git apply" uses strtoul() to parse the numbers in the hunk header but silently ignores overflows. As LONG_MAX is a legitimate return value for strtoul() we need to set errno to zero before the call to strtoul() and check that it is still zero afterwards. The error message we display is not particularly helpful as it does not say what was wrong. However, it seems pretty unlikely that users are going to trigger this error in practice and we can always improve it later if needed.

---
apply: detect overflow when parsing hunk header

We should do something similar in "git add -p" but I'll wait to see what happens with
https://lore.kernel.org/git/[email protected]/
first

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1858%2Fphillipwood%2Fapply-detect-hunk-header-overflow-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1858/phillipwood/apply-detect-hunk-header-overflow-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1858

 apply.c               |  3 +++
 t/t4100-apply-stat.sh | 13 +++++++++++++
 2 files changed, 16 insertions(+)

index 4a7b6120ac8..b124678b93b 100644
@@ -1423,7 +1423,10 @@ static int parse_num(const char *line, unsigned long *p)
 
 	if (!isdigit(*line))
 		return 0;
+	errno = 0;
 	*p = strtoul(line, &ptr, 10);
+	if (errno)
+		return 0;
 	return ptr - line;
 }
 

index 146e73d8f55..a5664f3eb3c 100755
@@ -38,4 +38,17 @@ incomplete (1)
 incomplete (2)
 EOF
 
+test_expect_success 'applying a hunk header which overflows fails' '
+	cat >patch <<-\EOF &&
+	diff -u a/file b/file
+	--- a/file
+	+++ b/file
+	@@ -98765432109876543210 +98765432109876543210 @@
+	-a
+	+b
+	EOF
+	test_must_fail git apply patch 2>err &&
+	echo "error: corrupt patch at line 4" >expect &&
+	test_cmp expect err
+'
 test_done

base-commit: fbe8d3079d4a96aeb4e4529cc93cc0043b759a05

gitgitgadget

Thanks. We made an effort to use a type that is a bit wider than "int", but we apparently ignored that the Git userbase will become a lot wider some day and unfriendly and/or hostile folks would start feeding malicious input to us X-<. The check presented here look good, and the fact that there was only one change needed shows how well designed the base code was ;-)

Will queue. Thanks.