aboutsummaryrefslogtreecommitdiff
path: root/src/common/mempool.c
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2010-12-13 18:40:21 -0500
committerNick Mathewson <nickm@torproject.org>2010-12-13 18:40:21 -0500
commit785086cfbaf15a78a921f5589a76517b1d4840b1 (patch)
tree452b47f3da27025aea6193ba045a6e97a0851a65 /src/common/mempool.c
parent649ee99846966c87350cd3282639326f8b4ee4af (diff)
downloadtor-785086cfbaf15a78a921f5589a76517b1d4840b1.tar
tor-785086cfbaf15a78a921f5589a76517b1d4840b1.tar.gz
Have all of our allocation functions and a few others check for underflow
It's all too easy in C to convert an unsigned value to a signed one, which will (on all modern computers) give you a huge signed value. If you have a size_t value of size greater than SSIZE_T_MAX, that is way likelier to be an underflow than it is to be an actual request for more than 2gb of memory in one go. (There's nothing in Tor that should be trying to allocate >2gb chunks.)
Diffstat (limited to 'src/common/mempool.c')
-rw-r--r--src/common/mempool.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/src/common/mempool.c b/src/common/mempool.c
index 256388a9f..1f79221b4 100644
--- a/src/common/mempool.c
+++ b/src/common/mempool.c
@@ -357,6 +357,10 @@ mp_pool_new(size_t item_size, size_t chunk_capacity)
mp_pool_t *pool;
size_t alloc_size, new_chunk_cap;
+ tor_assert(item_size < SIZE_T_CEILING);
+ tor_assert(chunk_capacity < SIZE_T_CEILING);
+ tor_assert(SIZE_T_CEILING / item_size > chunk_capacity);
+
pool = ALLOC(sizeof(mp_pool_t));
CHECK_ALLOC(pool);
memset(pool, 0, sizeof(mp_pool_t));