This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[PATCH] malloc: plug thread-cache memory leak
- From: Joern Engel <joern at purestorage dot com>
- To: "GNU C. Library" <libc-alpha at sourceware dot org>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, Joern Engel <joern at purestorage dot com>
- Date: Mon, 25 Jan 2016 16:25:31 -0800
- Subject: [PATCH] malloc: plug thread-cache memory leak
- Authentication-results: sourceware.org; auth=none
- References: <1453767942-19369-1-git-send-email-joern at purestorage dot com>
Freeing the cache into itself is an exploit worthy of MÃnchhausen. We
only leaked a little memory and only when destroying threads. But low
impact is no excuse for silly bugs.
JIRA: PURE-27597
---
tpc/malloc2.13/tcache.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/tpc/malloc2.13/tcache.h b/tpc/malloc2.13/tcache.h
index ece03fc464cd..b7bdb9ad41e4 100644
--- a/tpc/malloc2.13/tcache.h
+++ b/tpc/malloc2.13/tcache.h
@@ -226,6 +226,7 @@ static void tcache_destroy(void *_cache)
{
struct thread_cache *cache = _cache;
+ mutex_lock(&cache->mutex);
/*
* tcache_gc almost does what we want. It tries hard to only
* free part of the cache, but call it often enough and it
@@ -234,6 +235,15 @@ static void tcache_destroy(void *_cache)
*/
while (cache->tc_count)
tcache_gc(cache);
+ /*
+ * public_free will call tcache_free, which could free the
+ * cache into... the cache. Result would be a memory leak.
+ * But since we hold the cache-mutex, it cannot and has to
+ * free the memory back to the arena.
+ * A bit of a hack, but creates smaller code than having a
+ * second copy of uncached_free. And this is by no means a
+ * performance-critical path.
+ */
public_fREe(cache);
}
--
2.7.0.rc3