malloc: Switch global_max_fast to uint8_t

Message ID
State Committed
Commit 15a94e6668a6d7c5697e805d8d67f1d102d0d52e
Series malloc: Switch global_max_fast to uint8_t |


Context Check Description
dj/TryBot-apply_patch success Patch applied to master at the time it was sent
dj/TryBot-32bit success Build for i686

Commit Message

Florian Weimer Oct. 12, 2022, 2:02 p.m. UTC
  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(-)

base-commit: 264db94040c463d9bc356101595d89335586875e


DJ Delorie Oct. 12, 2022, 5:07 p.m. UTC | #1
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.

Reviewed-by: DJ Delorie <>


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.