You seem to be implying that execstr contains a value that's under the control of the input stream in a way that would allow malicious data on the input stream to cause the shell to invoke arbitrary code.
I read the run_callback() function, and I don't see that as plausible, unless you claiming there's a bug in sh_single_quote(). If that's the case, please be clear, and please provide a transcript of a session where sh_single_quote() returns an improperly protected string, either using mapfile or otherwise. Otherwise it is not appropriate to issue a CVE where no vulnerability exists. To be clear, it is not the shell's job to stop scripts from intentionally doing stupid things. Your "whoami" example just proves that the shell is working exactly as it should. If you have a case where a script provides an uncontrolled value as the argument to -C, that warrants a CVE be issued against the script, not against Bash. -Martin On Sat, 14 Sep 2024, 21:46 ~ via Bug reports for the GNU Bourne Again SHell, <bug-bash@gnu.org> wrote: > Dear bug-bash team: > I hope this email finds you well. During my recent security > assessment of bash, I identified a potential security vulnerability that I > believe may impact the security of your product and its users. > here is details: > 1、mapfile -C xxx will call run_callback > 2、evil "execstr" parameter passing causes rce > mapfile.def > > for example in bash shell: > echo -e > "line1\nline2\nline3\nline4\nline5\nline6\nline7\nline8\nline9\nline10" > > test.txt > mapfile -t -C "whoami #111" -c 5 my_array < test.txt > > > > I want to assign a CVE ID to the vulnerability > > > I look forward to working with you to address this matter promptly and > securely. Please feel free to contact me directly if you have any > questions or need further information. > > > Thank you for your attention to this matter.
