diff options
author | Andy Whitcroft <apw@shadowen.org> | 2007-05-15 17:33:25 +0100 |
---|---|---|
committer | Junio C Hamano <junkio@cox.net> | 2007-05-15 18:14:42 -0700 |
commit | cf606e3ddd8666b990a6560be77eb9f28af0e47d (patch) | |
tree | 4cf1c85058ac12ff55e61870b5220b5f7c2d000a /utf8.c | |
parent | Documentation/branch: fix small typo in -D example (diff) | |
download | tgif-cf606e3ddd8666b990a6560be77eb9f28af0e47d.tar.xz |
git name-rev writes beyond the end of malloc() with large generations
When using git name-rev on my kernel tree I triggered a malloc()
corruption warning from glibc.
apw@pinky$ git log --pretty=one $N/base.. | git name-rev --stdin
*** glibc detected *** malloc(): memory corruption: 0x0bff8950 ***
Aborted
This comes from name_rev() which is building the name of the revision
in a malloc'd string, which it sprintf's into:
char *new_name = xmalloc(len + 8);
[...]
sprintf(new_name, "%.*s~%d^%d", len, tip_name,
generation, parent_number);
This allocation is only sufficient if the generation number is
less than 5 digits, in my case generation was 13432. In reality
parent_number can be up to 16 so that also can require two digits,
reducing us to 3 digits before we are at risk of blowing this
allocation.
This patch introduces a decimal_length() which approximates the
number of digits a type may hold, it produces the following:
Type Longest Value Len Est
---- ------------- --- ---
unsigned char 256 3 4
unsigned short 65536 5 6
unsigned long 4294967296 10 11
unsigned long long 18446744073709551616 20 21
char -128 4 4
short -32768 6 6
long -2147483648 11 11
long long -9223372036854775808 20 21
This is then used to size the new_name.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'utf8.c')
0 files changed, 0 insertions, 0 deletions