As we iterate through the buffer containing git-log output, parsing lines, we use an "int" to store the size of an individual line. This should be a size_t, as we have no guarantee that there is not a malicious 2GB+ commit-message line in the output. Overflowing this integer probably doesn't do anything _too_ terrible. We are not using the value to size a buffer, so the worst case is probably an out-of-bounds read from before the array. But it's easy enough to fix. Note that we have to use ssize_t here, since we also store the length result from parse_git_diff_header(), which may return a negative value for error. That function actually returns an int itself, which has a similar overflow problem, but I'll leave that for another day. Much of the apply.c code uses ints and should be converted as a whole; in the meantime, a negative return from parse_git_diff_header() will be interpreted as an error, and we'll bail (so we can't handle such a case, but given that it's likely to be malicious anyway, the important thing is we don't have any memory errors). Signed-off-by: Jeff King <peff@xxxxxxxx> --- range-diff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/range-diff.c b/range-diff.c index 088db1b1ce..e731525e66 100644 --- a/range-diff.c +++ b/range-diff.c @@ -38,7 +38,7 @@ static int read_patches(const char *range, struct string_list *list, struct patch_util *util = NULL; int in_header = 1; char *line, *current_filename = NULL; - int len; + ssize_t len; size_t size; strvec_pushl(&cp.args, "log", "--no-color", "-p", "--no-merges", -- 2.33.0.rc1.475.g023efe0ae4
