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)
