Le ven. 19 nov. 2021 17h17 -0500, Chet Ramey a écrit :
> This fix is in the most recent set of patches I released this week
> (it's patch 9).
Thank you!
They've been merged a few days ago in the staging branch of NixOS:
https://github.com/NixOS/nixpkgs/pull/146463
On 10/12/21 3:38 PM, Julien Moutinho wrote:
Le mar. 05 oct. 2021 16h12 -0400, Chet Ramey a écrit :
On 10/5/21 1:50 PM, Dominique Martinet wrote:
If I change malloc_usable_size to return p->mh_nbytes instead of
maxbytes, then the crash disappears.[2]
That's the right fix.
Chet, when you'll
Le mar. 05 oct. 2021 16h12 -0400, Chet Ramey a écrit :
> On 10/5/21 1:50 PM, Dominique Martinet wrote:
> > If I change malloc_usable_size to return p->mh_nbytes instead of
> > maxbytes, then the crash disappears.[2]
>
> That's the right fix.
Chet, when you'll have time, would you mind publishing
On 10/5/21 1:50 PM, Dominique Martinet wrote:
> If I change malloc_usable_size to return p->mh_nbytes instead of
> maxbytes, then the crash disappears.[2]
>
> 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
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
Chet Ramey wrote on Mon, Oct 04, 2021 at 10:11:10PM -0400:
> > I'm running busybox sh in a unit (which starts properly), then
> > interactively test things from there.
> >
> > Running in gdb does fail the same way as running normally, so I've also
> > been looking at that a bit, but nothing
On 10/4/21 9:44 PM, Dominique Martinet wrote:
Chet Ramey wrote on Mon, Oct 04, 2021 at 09:23:11PM -0400:
- 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
Chet Ramey wrote on Mon, Oct 04, 2021 at 09:23:11PM -0400:
> > - 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
On 10/4/21 8:39 PM, Dominique Martinet wrote:
(not sure how that works? bash internal
malloc just passes to free pointers it doesn't know about?)
What does this mean? What pointers it doesn't know about? (If bash realloc
or free gets a pointer that wasn't allocated by the bash malloc, it
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
Dominique Martinet wrote on Tue, Oct 05, 2021 at 09:15:48AM +0900:
> - 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.
> This could mean that systemd is overflowing bash malloc safeguards
Hello,
(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
On Okt 04 2021, Chet Ramey wrote:
> You'd think. This is the kind of overflow that will produce that error
> message from the bash malloc:
Only after the fact. valgrind finds it before it is happening, and even
if the overflow hits a padding between memory blocks.
$ valgrind ./a.out
==31974==
On 10/4/21 4:44 PM, Andreas Schwab wrote:
On Okt 04 2021, Chet Ramey wrote:
I suspect this is a buffer overflow introduced between systemd-247 and
systemd-249. It's not caught when building bash without the bash malloc
because the default libc malloc probably doesn't do the bounds checking
On 10/4/21 5:28 PM, Julien Moutinho wrote:
On Okt 04 2021, Chet Ramey wrote:
I suspect this is a buffer overflow introduced between systemd-247 and
systemd-249. It's not caught when building bash without the bash malloc
because the default libc malloc probably doesn't do the bounds checking
the
On Okt 04 2021, Chet Ramey wrote:
> I suspect this is a buffer overflow introduced between systemd-247 and
> systemd-249. It's not caught when building bash without the bash malloc
> because the default libc malloc probably doesn't do the bounds checking
> the bash malloc does, even without malloc
On Okt 04 2021, Chet Ramey wrote:
> On 10/3/21 11:59 PM, Julien Moutinho wrote:
>> Bash Version: 5.1
>> Patch Level: 8
>> Release Status: release
>> Architecture: x86_64-linux
>>
>> Description:
>>
>> bash-5.1 reaches crashing code paths
>> when launched by systemd-249 or valgrind.
>> I cannot
Le lun. 04 oct. 2021 14h51 -0400, Chet Ramey a écrit :
> It's a problem with valgrind, described in another thread with this
> subject. Build bash with -DDISABLE_MALLOC_WRAPPERS to work around it.
Thanks Chet, that flag makes those crashes disappear.
However the crash after
On 10/3/21 11:59 PM, Julien Moutinho wrote:
> Bash Version: 5.1
> Patch Level: 8
> Release Status: release
> Architecture: x86_64-linux
>
> Description:
>
> bash-5.1 reaches crashing code paths
> when launched by systemd-249 or valgrind.
> I cannot get such crashes when bash is built using:
>
On 10/4/21 12:23 PM, Julien Moutinho wrote:
> Le lun. 04 oct. 2021 10h34 +0200, Andreas Schwab a écrit :
>> Here is a patch:
> Thanks Andreas, that particular crash disappears with this patch.
> However the crash after _nss_systemd_getpwuid_r() is still happening for me,
> and valgrind can still
On 10/4/21 12:27 PM, Andreas Schwab wrote:
> On Okt 04 2021, Chet Ramey wrote:
>
>> Nope. These are all functions internal to bash and the bash malloc, and
>> they are all defined.
>
> The problem is that the xmalloc macro redirects directly to the internal
> malloc implementation, whereas the
On Okt 04 2021, Chet Ramey wrote:
> Nope. These are all functions internal to bash and the bash malloc, and
> they are all defined.
The problem is that the xmalloc macro redirects directly to the internal
malloc implementation, whereas the xfree function calls it indirectly
through the free
Le lun. 04 oct. 2021 10h34 +0200, Andreas Schwab a écrit :
> Here is a patch:
Thanks Andreas, that particular crash disappears with this patch.
However the crash after _nss_systemd_getpwuid_r() is still happening for me,
and valgrind can still find a similar crash after source_builtin():
$ nix -L
On 10/4/21 11:08 AM, Andreas Schwab wrote:
> On Okt 04 2021, Chet Ramey wrote:
>
>> Nope, I don't buy that as the reason. xfree (name of function) and xfree(x)
>> (macro defined in xmalloc.h) are not the same thing.
>
> That's exactly the problem. You cannot pass the return value from
>
On Okt 04 2021, Chet Ramey wrote:
> Nope, I don't buy that as the reason. xfree (name of function) and xfree(x)
> (macro defined in xmalloc.h) are not the same thing.
That's exactly the problem. You cannot pass the return value from
sh_xmalloc to xfree, only sh_xfree.
> and everything works
On 10/4/21 10:17 AM, Andreas Schwab wrote:
> On Okt 04 2021, Chet Ramey wrote:
>
>> On 10/4/21 4:34 AM, Andreas Schwab wrote:
>>> On Okt 04 2021, Julien Moutinho wrote:
>>>
- bash crashes inside valgrind too,
but apparently something different is happening
because it crashes
On Okt 04 2021, Chet Ramey wrote:
> On 10/4/21 4:34 AM, Andreas Schwab wrote:
>> On Okt 04 2021, Julien Moutinho wrote:
>>
>>> - bash crashes inside valgrind too,
>>> but apparently something different is happening
>>> because it crashes even without systemd being involved:
>>>
>>> $ nix
On 10/4/21 4:34 AM, Andreas Schwab wrote:
> On Okt 04 2021, Julien Moutinho wrote:
>
>> - bash crashes inside valgrind too,
>> but apparently something different is happening
>> because it crashes even without systemd being involved:
>>
>> $ nix build .#bash5-with-bash-malloc
>> $ valgrind
On Okt 04 2021, Julien Moutinho wrote:
> - bash crashes inside valgrind too,
> but apparently something different is happening
> because it crashes even without systemd being involved:
>
> $ nix build .#bash5-with-bash-malloc
> $ valgrind result/bin/bash --norc -c true
>> ==307088== Memcheck,
29 matches
Mail list logo
