# More "git-apply" safety fixes 1 messages from 2006-03-25 to 2006-03-25. Participants: Linus Torvalds. Thread: https://gitlist.dev/t/3723 ## Linus Torvalds, 2006-03-25 21:28 Subject: More "git-apply" safety fixes Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0603251321330.15714%40g5.osdl.org ``` This was triggered by me testing the "@@" numbering shorthand by GNU patch, which not only showed that git-apply thought it meant the number was duplicated (when it means that the second number is 1), but my tests showed than when git-apply mis-understood the number, it would then not raise an alarm about it if the patch ended early. Now, this doesn't actually _matter_, since with a three-line context, the only case that "x,1" will be shorthanded to "x" is when x itself is 1 (in which case git-apply got it right), but the fact that git-apply would also silently accept truncated patches was a missed opportunity for additional sanity-checking. So make git-apply refuse to look at a patch fragment that ends early. Signed-off-by: Linus Torvalds ---- If you already applied the first hunk, just ignore that part, and apply the second one that adds the test for oldlines/newlines being zero after the patch. Neither of these two changes should matter for a well-formed patch, but it's definitely the right thing to do. diff --git a/apply.c b/apply.c index 2da225a..c50b3a6 100644 --- a/apply.c +++ b/apply.c @@ -693,7 +693,7 @@ static int parse_range(const char *line, line += digits; len -= digits; - *p2 = *p1; + *p2 = 1; if (*line == ',') { digits = parse_num(line+1, p2); if (!digits) @@ -901,6 +901,8 @@ static int parse_fragment(char *line, un break; } } + if (oldlines || newlines) + return -1; /* If a fragment ends with an incomplete line, we failed to include * it in the above loop because we hit oldlines == newlines == 0 * before seeing it. ```