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