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

[Chet Ramey]

On 10/4/21 8:15 PM, Dominique Martinet wrote:

> (I've been following this with Julien as I can reproduce the behaviour
> on my nixos system -- you don't have to run the latest systemd, just
> install the derivation and use its path in LD_LIBRARY_PATH instead of
> the system's... That also probably could bring its own set of
> incompatibility but so far I'm getting the same behaviour as him running
> systemd properly)

I'd love to have a simpler reproducer here. It's just hard for me to see
how just changing systemd, and nothing else, produces an error. There might
be some obscure bug in the bash malloc, but the code we're talking about
here -- the code that detects overflow -- hasn't changed in years.

> OTOH, valgrind *should* complain when using the system malloc (configure
> --without-bash-malloc), and it does not, so for me that means there
> really is some weird thing happening. Forgive me for trusting valgrind
> analysis more than bash malloc debugging here...

The bash overflow detection is much less sophisticated than valgrind,
that's for sure, but it's so simple it's fairly easy to verify.


>   - I could reproduce the same as Julien, with -DDISABLE_MALLOC_WRAPPERS
> the crash still happens when bash is run directly but nothing complains
> in valgrind.

I assume you mean using systemd. Has anyone tried running a bash linked to
the systemd library that provides the getpw functions, but not as a systemd
unit? You could then run it in a debugger if it crashes, for instance.

> This could mean that systemd is overflowing bash malloc safeguards as
> you pointed out (I just don't understand why it wouldn't overflow with
> internal malloc), but it could also mean that the memory has been
> allocated somewhere else (e.g. libc's malloc) and freed by bash malloc.

I have a tough time with that one. If the bash free/realloc get memory that
the bash malloc hasn't allocated, you're going to fail several sanity tests
before you get to the point of checking for overflow.

> nss systemd has started using reallocarray() since v247 and that is not
> tracked by bash, I would think that's a good candidate?

I can't see how? reallocarray() is not a memory allocation primitive. It's
going to call malloc/realloc to do its work (it's essentially just a call
to realloc(mem, nmemb * size)). Those will eventually call the bash
malloc/realloc/free.

> I don't have time right now, but I think adding an implementation for
> reallocarray (wrapper around realloc which does exist) would be the next
> thing to do.

You could try it, but I'm skeptical that it will have any effect.


--
``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/