Skip to content

patch_parse: fixes for fuzzing errors#5276

Merged
pks-t merged 4 commits intolibgit2:masterfrom
pks-t:pks/patch-fuzzing-fixes
Oct 29, 2019
Merged

patch_parse: fixes for fuzzing errors#5276
pks-t merged 4 commits intolibgit2:masterfrom
pks-t:pks/patch-fuzzing-fixes

Conversation

@pks-t
Copy link
Copy Markdown
Member

@pks-t pks-t commented Oct 19, 2019

These are the first results of #5269.

pks-t added 3 commits October 19, 2019 17:02
It's currently possible to have patches with multiple old path name
headers. As we didn't check for this case, this resulted in a memory
leak when overwriting the old old path with the new old path because we
simply discarded the old pointer.

Instead of fixing this by free'ing the old pointer, we should reject
such patches altogether. It doesn't make any sense for the "---" or
"+++" markers to occur multiple times within a patch n the first place.
This also implicitly fixes the memory leak.
When parsing patch headers, we currently accept empty path names just
fine, e.g. a line "--- \n" would be parsed as the empty filename. This
is not a valid patch format and may cause `NULL` pointer accesses at a
later place as `git_buf_detach` will return `NULL` in that case.

Reject such patches as malformed with a nice error message.
We've got two locations where we copy lines into the patch. The first
one is when copying normal " ", "-" or "+" lines, while the second
location gets executed when we copy "\ No newline at end of file" lines.
While the first one correctly uses `git__strndup` to copy only until the
newline, the other one doesn't. Thus, if the line occurs at the end of
the patch and if there is no terminating NUL character, then it may
result in an out-of-bounds read.

Fix the issue by using `git__strndup`, as was already done in the other
location. Furthermore, add allocation checks to both locations to detect
out-of-memory situations.
@pks-t pks-t force-pushed the pks/patch-fuzzing-fixes branch 2 times, most recently from dd207f5 to 3cfd4ac Compare October 21, 2019 17:08
When the patch contains lines close to INT_MAX, then it may happen that
we end up with an integer overflow when calculating the line of the
current diff hunk. Reject such patches as unreasonable to avoid the
integer overflow.

As the calculation is performed on integers, we introduce two new
helpers `git__add_int_overflow` and `git__sub_int_overflow` that perform
the integer overflow check in a generic way.
@pks-t pks-t force-pushed the pks/patch-fuzzing-fixes branch from 3cfd4ac to 37141ff Compare October 21, 2019 18:08
@pks-t
Copy link
Copy Markdown
Member Author

pks-t commented Oct 29, 2019

I'm going ahead and merge this. The fixes should be rather obvious, and these bugs currently hinder progress of the fuzzer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant