On 10/5/21 1:50 PM, Dominique Martinet wrote:
> Turns out I'm lucky enough on address consistency..
>
> So,
> - since we have a nice before/after with systemd, I took a moment to
> bisect it.
> It comes down to this commit[1] which is basically using
> malloc_usable_size() to use buffers beyond what it initially requested
>
> [1]
> https://github.com/systemd/systemd/commit/319a4f4bc46b230fc660321e99aaac1bc449deea
>
> - through gdb/printf I see that the failing pointer has been allocated
> with (what comes down to) malloc(64), but malloc_usable_size returns
> 108, so systemd happily writes beyond the 64 bytes it originally
> requested -- which bash allocator treats as an overflow.
Sure. The bash malloc_usable_size basically returns the size of the chunk:
what you could realloc it to without having to go back for more memory
(that's how I interpreted `usable bytes', but that's clearly not how it's
intended). I suppose without the bounds checking that would have been fine.
> If I change malloc_usable_size to return p->mh_nbytes instead of
> maxbytes, then the crash disappears.[2]
That's the right fix.
>
> I did not read the full bash malloc code but I suspect the buffer really
> could be grown, but we would need to fix p->mh_nbytes to maxbytes and
> also adjust the end block to pass sanity checks on free -- e.g. it
> should be considered as a lightweight inplace realloc.
If you want realloc, use realloc.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
