user/sven/git.git/patch-delta.c, branch v2.26.0-rc2

patch-delta: handle truncated copy parameters

2018-08-30T17:30:23Z

When we see a delta command instructing us to copy bytes from the base, we have to read the offset and size from the delta stream. We do this without checking whether we're at the end of the stream, meaning we may read past the end of the buffer. In practice this isn't exploitable in any interesting way because: 1. Deltas are always in packfiles, so we have at least a 20-byte trailer that we'll end up reading. 2. The worst case is that we try to perform a nonsense copy from the base object into the result, based on whatever was in the pack stream next. In most cases this will simply fail due to our bounds-checks against the base or the result. But even if you carefully constructed a pack stream for which it succeeds, it wouldn't perform any delta operation that you couldn't have simply included in a non-broken form. But obviously it's poor form to read past the end of the buffer we've been given. Unfortunately there's no easy way to do a single length check, since the number of bytes we need depends on the number of bits set in the initial command byte. So we'll just check each byte as we parse. We can hide the complexity in a macro; it's ugly, but not as ugly as writing out each individual conditional. Signed-off-by: Jeff King Reviewed-by: Nicolas Pitre Signed-off-by: Junio C Hamano

patch-delta: consistently report corruption

2018-08-30T17:30:22Z

When applying a delta, if we see an opcode that cannot be fulfilled (e.g., asking to write more bytes than the destination has left), we break out of our parsing loop but don't signal an explicit error. We rely on the sanity check after the loop to see if we have leftover delta bytes or didn't fill our result buffer. This can silently ignore corruption when the delta buffer ends with a bogus command and the destination buffer is already full. Instead, let's jump into the error handler directly when we see this case. Note that the tests also cover the "bad opcode" case, which already handles this correctly. Signed-off-by: Jann Horn Signed-off-by: Jeff King Reviewed-by: Nicolas Pitre Signed-off-by: Junio C Hamano

patch-delta: fix oob read

2018-08-30T17:30:22Z

If `cmd` is in the range [0x01,0x7f] and `cmd > top-data`, the `memcpy(out, data, cmd)` can copy out-of-bounds data from after `delta_buf` into `dst_buf`. This is not an exploitable bug because triggering the bug increments the `data` pointer beyond `top`, causing the `data != top` sanity check after the loop to trigger and discard the destination buffer - which means that the result of the out-of-bounds read is never used for anything. Signed-off-by: Jann Horn Signed-off-by: Jeff King Reviewed-by: Nicolas Pitre Signed-off-by: Junio C Hamano

compat: helper for detecting unsigned overflow

2011-02-10T21:47:56Z

The idiom (a + b < a) works fine for detecting that an unsigned integer has overflowed, but a more explicit unsigned_add_overflows(a, b) might be easier to read. Define such a macro, expanding roughly to ((a) < UINT_MAX - (b)). Because the expansion uses each argument only once outside of sizeof() expressions, it is safe to use with arguments that have side effects. Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

Fix integer overflow in patch_delta()

2010-01-26T20:57:59Z

Signed-off-by: Ilari Liusvaara Signed-off-by: Junio C Hamano

Nicolas Pitre has a new email address

2009-09-14T09:23:36Z

Due to problems at cam.org, my nico@cam.org email address is no longer valid. From now on, nico@fluxnic.net should be used instead. Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano

Fix big left-shifts of unsigned char

2009-06-18T16:22:46Z

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. I may have missed some, but this is the result of looking at git grep '[^0-9 ][ ]*<<[ ][a-z]' -- '*.c' '*.h' git grep '<<[ ]*24' which catches at least the common byte cases (shifting variables by a variable amount, and shifting by 24 bits). I also grepped for just 'unsigned char' variables in general, and converted the ones that most obviously ended up getting implicitly cast immediately anyway (eg hash_name(), encode_85()). In addition to just avoiding 'unsigned char', this patch also tries to use a common idiom for the delta header size thing. We had three different variations on it: "& 0x7fUL" in one place (getting the sign extension right), and "& ~0x80" and "& 0x7f" in two other places (not getting it right). Apart from making them all just avoid using "unsigned char" at all, I also unified them to then use a simple "& 0x7f". I considered making a sparse extension which warns about doing implicit casts from unsigned types to signed types, but it gets rather complex very quickly, so this is just a hack. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano

make patch_delta() error cases a bit more verbose

2006-12-18T23:30:17Z

It is especially important to distinguish between a malloc() failure from all the other cases. An out of memory condition is much less worrisome than a compatibility/corruption problem. Also make test-delta compilable again. Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano

Remove all void-pointer arithmetic.

2006-06-20T08:59:46Z

ANSI C99 doesn't allow void-pointer arithmetic. This patch fixes this in various ways. Usually the strategy that required the least changes was used. Signed-off-by: Florian Forster Signed-off-by: Junio C Hamano

split the diff-delta interface

2006-04-25T05:27:33Z

This patch splits the diff-delta interface into index creation and delta generation. A wrapper is provided to preserve the diff-delta() call. This will allow for an optimization in pack-objects.c where the source object could be fixed and a full window of objects tentatively tried against that same source object without recomputing the source index each time. This patch only restructure things, plus a couple cleanups for good measure. There is no performance change yet. Signed-off-by: Nicolas Pitre