This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] malloc: plug thread-cache memory leak

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)
+	/*
+	 * 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.
+	 */

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]