Prevent reading out of bounds memory#4996
Prevent reading out of bounds memory#4996pks-t merged 2 commits intolibgit2:masterfrom eaigner:master
Conversation
|
Test suite runs through, not quite sure how to distill a test case from this though. |
| Emeric Fermas | ||
| Emmanuel Rodriguez | ||
| Eric Myhre | ||
| Erik Aigner |
There was a problem hiding this comment.
Oh, been a long time since this file actually got amended. I'm still not part of it myself :P
|
|
||
| for (start = in; start < in + in_len; start = end) { | ||
| end = memchr(start, '\n', in_len); | ||
| end = memchr(start, '\n', in_len - (start - in)); |
There was a problem hiding this comment.
I usually try to not be over-eager in enforcing commit message style, but in this case I think it'd help quite a lot if your commit actually explains the overflow and says why this change is necessary. It'd also make reviewing a lot easier for us :)
While already at it, you might also adjust the subject line of the commit message to something like e.g. "apply: prevent OOB read when reading patch image", just so that we know on first sight that the fix is about our apply code.
There was a problem hiding this comment.
By the way: it's not necessary to have the ticket ID in commit messages. After all, if we ever decide to move to a ticketing system other than GitHub, then those might get invalidated either way.
When parsing the patch image from a string, we split the string by newlines to get a line-based view of it. To split, we use `memchr` on the buffer and limit the buffer length by the original length provided by the caller. This works just fine for the first line, but for every subsequent line we need to actually subtract the amount of bytes that we have already read. The above issue can be easily triggered by having a source buffer with at least two lines, where the second line does _not_ end in a newline. Given a string "foo\nb", we have an original length of five bytes. After having extracted the first line, we will point to 'b' and again try to `memchr(p, '\n', 5)`, resulting in an out-of-bounds read of four bytes. Fix the issue by correctly subtracting the amount of bytes already read.
|
I've added a test that catches the OOB read and changed the commit message. Naturally, I've kept the authorship of your commit, so I hope you don't mind :) |
|
Thanks for the edits. The other issue was #4972, but I'm not sure if it is related. |
|
Oh, that was it, thanks for reminding me. This definitely isn't related at all |
Previously, we would fail to correctly truncate the source buffer if the source has more than one line and ends with a non-newline character. In the following call, we thus truncate the source string in the middle of the second line. Without the bug fixed, we would successfully apply the patch to the source and return success. With the overflow being fixed, we should return an error now.
|
Thanks a lot, @eaigner! :) |
Closes #4993