tests/diff/binary.c


Log

Author Commit Date CI Message
Patrick Steinhardt 7db25870 2018-06-29T07:45:18 delta: fix sign-extension of big left-shift Our delta code was originally adapted from JGit, which itself adapted it from git itself. Due to this heritage, we inherited a bug from git.git in how we compute the delta offset, which was fixed upstream in 48fb7deb5 (Fix big left-shifts of unsigned char, 2009-06-17). As explained by Linus: Shifting 'unsigned char' or 'unsigned short' left can result in sign extension errors, since the C integer promotion rules means that the unsigned char/short will get implicitly promoted to a signed 'int' due to the shift (or due to other operations). This normally doesn't matter, but if you shift things up sufficiently, it will now set the sign bit in 'int', and a subsequent cast to a bigger type (eg 'long' or 'unsigned long') will now sign-extend the value despite the original expression being unsigned. One example of this would be something like unsigned long size; unsigned char c; size += c << 24; where despite all the variables being unsigned, 'c << 24' ends up being a signed entity, and will get sign-extended when then doing the addition in an 'unsigned long' type. Since git uses 'unsigned char' pointers extensively, we actually have this bug in a couple of places. In our delta code, we inherited such a bogus shift when computing the offset at which the delta base is to be found. Due to the sign extension we can end up with an offset where all the bits are set. This can allow an arbitrary memory read, as the addition in `base_len < off + len` can now overflow if `off` has all its bits set. Fix the issue by casting the result of `*delta++ << 24UL` to an unsigned integer again. Add a test with a crafted delta that would actually succeed with an out-of-bounds read in case where the cast wouldn't exist. Reported-by: Riccardo Schirone <rschiron@redhat.com> Test-provided-by: Riccardo Schirone <rschiron@redhat.com>
Patrick Steinhardt ecf4f33a 2018-02-08T11:14:48 Convert usage of `git_buf_free` to new `git_buf_dispose`
Guille -bisho- e4b2b919 2015-09-25T10:37:41 Fix binary diffs git expects an empty line after the binary data: literal X ...binary data... <empty_line> The last literal block of the generated patches were not containing the required empty line. Example: diff --git a/binary_file b/binary_file index 3f1b3f9098131cfecea4a50ff8afab349ea66d22..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644 GIT binary patch literal 8 Pc${NM&PdElPvrst3ey5{ literal 6 Nc${NM%g@i}0ssZ|0lokL diff --git a/binary_file2 b/binary_file2 index 31be99be19470da4af5b28b21e27896a2f2f9ee2..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644 GIT binary patch literal 8 Pc${NM&PdElPvrst3ey5{ literal 13 Sc${NMEKbZyOexL+Qd|HZV+4u- git apply of that diff results in: error: corrupt binary patch at line 9: diff --git a/binary_file2 b/binary_file2 fatal: patch with only garbage at line 10 The proper formating is: diff --git a/binary_file b/binary_file index 3f1b3f9098131cfecea4a50ff8afab349ea66d22..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644 GIT binary patch literal 8 Pc${NM&PdElPvrst3ey5{ literal 6 Nc${NM%g@i}0ssZ|0lokL diff --git a/binary_file2 b/binary_file2 index 31be99be19470da4af5b28b21e27896a2f2f9ee2..86e5c1008b5ce635d3e3fffa4434c5eccd8f00b6 100644 GIT binary patch literal 8 Pc${NM&PdElPvrst3ey5{ literal 13 Sc${NMEKbZyOexL+Qd|HZV+4u-
Carlos Martín Nieto fa399750 2015-06-27T21:26:27 Merge pull request #3265 from libgit2/leaks Plug a bunch of leaks
Carlos Martín Nieto 9568660f 2015-06-26T18:31:39 diff: fix leaks in diff printing
Pierre-Olivier Latour 492851c9 2015-06-26T08:18:06 Removed unused variables
Edward Thomson ba8fb7c4 2015-06-24T11:39:59 diff::binary tests: empty diff when forced binary Ensure that even when we're forcing a binary diff that we do not assume that there *is* a diff. There should be an empty diff for no change.
Carlos Martín Nieto 76633215 2015-06-24T14:25:36 binary diff: test that the diff and patch otputs are the same We test the generation of the textual patch via the patch function, which are just one of two possibilities to get the output. Add a second patch generation via the diff function to make sure both outputs are in sync.
Pierre-Olivier Latour 0f4d9c03 2015-06-15T09:52:40 Fixed Xcode 6.1 build warnings
Edward Thomson 391281ae 2015-06-02T18:26:22 binary diff: test binary blob to blob tests
Edward Thomson ac7012a8 2015-05-25T20:36:29 binary diff: test index->workdir binary diffs
Edward Thomson e349ed50 2014-04-22T14:58:33 patch: emit binary patches (optionally)