request2size can cause unintentional overflow in the program

[Florian Weimer]

* just4you:

> /* stdout:
> a demo used to expose the dangers of request2size
> actual size obtained = 0x40
> actual usable size = 0x40
> when alloc size 0x36, marco [request2size] gave us an incorrect value
> actual size obtained = 0x50
> actual usable size = 0x50
> alloc size 0x39 succeed, has enough space to use */
>
> problem description:

> I'm learning about off-by-one operations in heap scenarios. While
> understanding the `request2size` macro, I noticed that during the size
> conversion process, it splits the value into the form `n * 0x10 + x
> `. For example, 0x36 becomes `0x3 * 0x10 + 0x6`, then offsets upwards
> and aligns with `MALLOC_ALIGN_MASK`.

>  If `x` is less than or equal to 8, the `request2size` macro returns
> `(n + 1) * 0x10` as the chunk size.  However, because the chunk needs
> to reserve space for `CHUNK_HDR_SZ`, the actual usable space is only
> `n * 0x10`, which is `x` bytes less than the actual required space.
> This situation can cause unintentional overflow in the program.

No, glibc malloc needs to reserve only half of CHUNK_HDR_SZ, due to the
way the PREV_INUSE bit is used: the footer can be used by the
application while the chunk is allocated.

Does this address your concern?

Thanks,
Florian