Message ID | 87bkqhywbg.fsf@oldenburg.str.redhat.com |
---|---|
State | New |
Headers | show |
Series | malloc: Switch global_max_fast to uint8_t | expand |
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>
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.