summaryrefslogtreecommitdiff
path: root/fast-import.c
diff options
context:
space:
mode:
authorYONETANI Tomokazu <qhwt+git@les.ath.cx>2008-12-14 11:08:22 +0900
committerJunio C Hamano <gitster@pobox.com>2008-12-14 16:41:32 -0800
commit2fad5329f4bc03e2328a2994d336c12a9683d9b2 (patch)
tree43285f131f69c8e87fb0d08042c435b303e4c878 /fast-import.c
parent7e76aba317b690932c8236311219b0faf97f1571 (diff)
downloadgit-2fad5329f4bc03e2328a2994d336c12a9683d9b2.tar.gz
git-fast-import possible memory corruption problem
Internal "allocate in bulk, we will never free this memory anyway" allocator used in fast-import had a logic to round up the size of the requested memory block in a wrong place (it computed if the available space is enough to fit the request first, and then carved a chunk of memory by size rounded up to the alignment, which could go beyond the actually available space). Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'fast-import.c')
-rw-r--r--fast-import.c7
1 files changed, 4 insertions, 3 deletions
diff --git a/fast-import.c b/fast-import.c
index 3c035a5788..3276d5d7aa 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -554,6 +554,10 @@ static void *pool_alloc(size_t len)
struct mem_pool *p;
void *r;
+ /* round up to a 'uintmax_t' alignment */
+ if (len & (sizeof(uintmax_t) - 1))
+ len += sizeof(uintmax_t) - (len & (sizeof(uintmax_t) - 1));
+
for (p = mem_pool; p; p = p->next_pool)
if ((p->end - p->next_free >= len))
break;
@@ -572,9 +576,6 @@ static void *pool_alloc(size_t len)
}
r = p->next_free;
- /* round out to a 'uintmax_t' alignment */
- if (len & (sizeof(uintmax_t) - 1))
- len += sizeof(uintmax_t) - (len & (sizeof(uintmax_t) - 1));
p->next_free += len;
return r;
}