[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bash encountered a coredump issue with stepping on memory
From: |
Ángel |
Subject: |
Re: bash encountered a coredump issue with stepping on memory |
Date: |
Wed, 03 Jan 2024 19:33:10 +0100 |
On 2023-12-06 at 07:20 -0500, Greg Wooledge wrote:
> On Wed, Dec 06, 2023 at 05:28:19PM +0800, wang yuhang via Bug reports for the
> GNU Bourne Again SHell wrote:
> > When the for loop reaches env, the values of each env are:
> >
> [...]
> > (gdb) p env[16]
> > $21 = 0x7ffce3c2e25a "DIRNAME_ALIAS"
> > (gdb) p env[17]
> > $22 = 0x7ffce3c2e279 "PID="
>
> The missing '=' in DIRNAME_ALIAS appears to be noteworthy.
>
> I could imagine a library function scanning through these strings, and
> for each one, iterating from the start and looking for '='. In the
> case of DIRNAME_ALIAS, it never finds one, so it marches off past the
> edge of the allocated memory chunk.
>
> This is pure speculation, of course, until someone actually tests it.
>
Good point, but...
bash skips such variables, and they are not passed to the child
environment:
variables.c:382
+ /* If there are weird things in the environment, like `=xxx' or a
+ string without an `=', just skip them. */
+ if (char_index == 0)
+ continue;
which have been there at least since... 1997 (bash 2.01)
So there's no need to use any arena by glibc. That entry will be
skipped...
I don't see how this may end up in such situation (assuming bash itself
is not modified, and there are not weird libraries or modules enabled)
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: bash encountered a coredump issue with stepping on memory,
Ángel <=