Re: Using systemd-249's libnss_systemd.so.2 triggers a crash in bash-5.1's malloc.c

[Chet Ramey]

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    chet@case.edu    http://tiswww.cwru.edu/~chet/