summaryrefslogtreecommitdiff
path: root/src/zmalloc.c
diff options
context:
space:
mode:
authorYossi Gottlieb <yossigo@gmail.com>2020-10-26 14:49:08 +0200
committerGitHub <noreply@github.com>2020-10-26 14:49:08 +0200
commit9824fe3e392caa04dc1b4071886e9ac402dd6d95 (patch)
tree5a084b5fd9171ae0f5abd81e17fa270387db81e8 /src/zmalloc.c
parent4e2e5be201439cae4c0a03cfc8b6a60be4bff625 (diff)
downloadredis-9824fe3e392caa04dc1b4071886e9ac402dd6d95.tar.gz
Fix wrong zmalloc_size() assumption. (#7963)
When using a system with no malloc_usable_size(), zmalloc_size() assumed that the heap allocator always returns blocks that are long-padded. This may not always be the case, and will result with zmalloc_size() returning a size that is bigger than allocated. At least in one case this leads to out of bound write, process crash and a potential security vulnerability. Effectively this does not affect the vast majority of users, who use jemalloc or glibc. This problem along with a (different) fix was reported by Drew DeVault.
Diffstat (limited to 'src/zmalloc.c')
-rw-r--r--src/zmalloc.c3
1 files changed, 0 insertions, 3 deletions
diff --git a/src/zmalloc.c b/src/zmalloc.c
index 4a7f2028e..565376721 100644
--- a/src/zmalloc.c
+++ b/src/zmalloc.c
@@ -236,9 +236,6 @@ void *zrealloc_usable(void *ptr, size_t size, size_t *usable) {
size_t zmalloc_size(void *ptr) {
void *realptr = (char*)ptr-PREFIX_SIZE;
size_t size = *((size_t*)realptr);
- /* Assume at least that all the allocations are padded at sizeof(long) by
- * the underlying allocator. */
- if (size&(sizeof(long)-1)) size += sizeof(long)-(size&(sizeof(long)-1));
return size+PREFIX_SIZE;
}
size_t zmalloc_usable_size(void *ptr) {