execve E2BIG (Argument list too long)

[Michael Green]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wno-parentheses -Wno-format-security
uname output: Linux h001201355 5.7.10-201.fc32.x86_64 #1 SMP Thu Jul
23 00:58:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.0
Patch Level: 17
Release Status: release

Description:

The included short script when run with the following command results
in execve "E2BIG (Argument list too long) errors".

Running "strace -f" on this shows the error, and "Argument list too
long" is printed out to stderr for the calls to external commands.

seq 1 40000 | xargs ./bash_bug

BEGIN: bash_bug
--------------------------------------
#!/usr/bin/env bash
. "exists_or_not"
export A123456789012345="${BASH_ARGV[*]}"
mkdir -p /tmp/foobar
perl -E 'say "hello world"' 'foo' 'bar'
--------------------------------------
END bash_bug

"xargs" is only used for the sake of being concise. The issue occurs
with an equivalently long list of arguments.

A number of the parameters can be tuned to make the problem occur or not.

* The number of arguments can be tuned down to "seq 1 23694" and it
still occurs, but any lower and it disappears.

* The sourcing of a file appears to be required, but it doesn't matter
what that file is or even if it exists.

* The variable name length of the exported variable must be 16 or more
characters, reducing this to 15 or less makes the bug disappear. It
also doesn't matter what characters are, any valid variable name of 16
or more characters will do.

* The path used for calling the script seems to affect the issue. In
my tests using the absolute script path sometimes made the bug
disappear, but using a local relative path seemed to reliably produce
it.

This issue was tested on the reporting system and the oldest system I
could find and was present on both systems

* Fedora release 32 (Thirty Two) 5.7.10-201.fc32.x86_64
* Red Hat Enterprise Linux Server release 6.10 (Santiago)
2.6.32-754.3.5.el6.x86_64


Repeat-By:

Running provided script with the given command.