[PATCH] malloc: Switch global_max_fast to uint8_t

[PATCH] malloc: Switch global_max_fast to uint8_t

[Florian Weimer]

MAX_FAST_SIZE is 160 at most, so a uint8_t is sufficient.  This makes
it harder to use memory corruption, by overwriting global_max_fast
with a large value, to fundamentally alter malloc behavior.

Tested i686-linux-gnu and x86_64-linux-gnu.

---
 malloc/malloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/malloc/malloc.c b/malloc/malloc.c
index 953183e956..2a61c8b5ee 100644
--- a/malloc/malloc.c
+++ b/malloc/malloc.c
@@ -1757,7 +1757,7 @@ typedef struct malloc_chunk *mfastbinptr;
 #define set_contiguous(M)      ((M)->flags &= ~NONCONTIGUOUS_BIT)
 
 /* Maximum size of memory handled in fastbins.  */
-static INTERNAL_SIZE_T global_max_fast;
+static uint8_t global_max_fast;
 
 /*
    Set value of max_fast.

base-commit: 264db94040c463d9bc356101595d89335586875e

Re: [PATCH] malloc: Switch global_max_fast to uint8_t

[DJ Delorie]

set_max_fast() doesn't itself check the value passed to it, but it's
only ever called twice:  once at startup with a constant, and once from
tunables where the value is checked.

so we're only concerned with malicious overwriting, ok.

The wiki agrees that the maximum value on current targets is 160.

0..255 still allows corruption, but limits the corruption.  I suppose
with a 32 bit or 64 bit value we could currupt things to the point where
we could generate arbitrary addresses.  So I see how this limits the
attack surface.

I suspect with today's processors, reading an 8-bit value into a 32-bit
register adds no overhead.

Both INTERNAL_SIZE_T and uint8_t are unsigned, so there's no logic
changes there.

LGTM
Reviewed-by: DJ Delorie <dj@redhat.com>