summaryrefslogtreecommitdiff
path: root/contrib/coccinelle/array.cocci
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-03-24 13:26:40 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-03-24 12:34:07 -0700
commit7202a6fa8773fdcf3f374625def3c15276250b67 (patch)
tree96063a317f76e15fac6e73a0d1754b55f499ee87 /contrib/coccinelle/array.cocci
parentfast-import: use xsnprintf for formatting headers (diff)
downloadtgif-7202a6fa8773fdcf3f374625def3c15276250b67.tar.xz
encode_in_pack_object_header: respect output buffer length
The encode_in_pack_object_header() writes a variable-length header to an output buffer, but it doesn't actually know long the buffer is. At first glance, this looks like it might be possible to overflow. In practice, this is probably impossible. The smallest buffer we use is 10 bytes, which would hold the header for an object up to 2^67 bytes. Obviously we're not likely to see such an object, but we might worry that an object could lie about its size (causing us to overflow before we realize it does not actually have that many bytes). But the argument is passed as a uintmax_t. Even on systems that have __int128 available, uintmax_t is typically restricted to 64-bit by the ABI. So it's unlikely that a system exists where this could be exploited. Still, it's easy enough to use a normal out/len pair and make sure we don't write too far. That protects the hypothetical 128-bit system, makes it harder for callers to accidentally specify a too-small buffer, and makes the resulting code easier to audit. Note that the one caller in fast-import tried to catch such a case, but did so _after_ the call (at which point we'd have already overflowed!). This check can now go away. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/coccinelle/array.cocci')
0 files changed, 0 insertions, 0 deletions