Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

eaigner
Copy link

@eaigner eaigner commented Feb 20, 2019

Closes #4993

@eaigner
Copy link
Author

eaigner commented Feb 20, 2019

Test suite runs through, not quite sure how to distill a test case from this though.

Copy link
Member

@pks-t pks-t left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool that you finally found the issue! Does this explain both #4993 and the other issue you had (can't remember the ID here)?

@@ -23,6 +23,7 @@ Dmitry Kovega
Emeric Fermas
Emmanuel Rodriguez
Eric Myhre
Erik Aigner
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, been a long time since this file actually got amended. I'm still not part of it myself :P

@@ -59,7 +59,7 @@ static int patch_image_init_fromstr(
git_pool_init(&out->pool, sizeof(git_diff_line));

for (start = in; start < in + in_len; start = end) {
end = memchr(start, '\n', in_len);
end = memchr(start, '\n', in_len - (start - in));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
@pks-t
Copy link
Member

pks-t commented Feb 21, 2019

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 :)

@eaigner
Copy link
Author

eaigner commented Feb 21, 2019

Thanks for the edits. The other issue was #4972, but I'm not sure if it is related.

@pks-t
Copy link
Member

pks-t commented Feb 21, 2019

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.
@pks-t pks-t merged commit 554b3b9 into libgit2:master Feb 21, 2019
@pks-t
Copy link
Member

pks-t commented Feb 21, 2019

Thanks a lot, @eaigner! :)

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.

git_apply corrupts file if no NL at EOF
2 participants