[PATCH] bind_assoc_variable: free key if cannot assign

Avoid leaking expansion of `x' in `declare -Ar A; A[x]=' --- arrayfunc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arrayfunc.c b/arrayfunc.c index e85ba6e5..aaa1963c 100644 --- a/arrayfunc.c +++ b/arrayfunc.c @@ -302,6 +302,7 @@ bind_assoc_variable (SHELL_VAR *entry, const char *name, c

Re: [PATCH] read: free ifs_chars

On 5/29/24 3:31 PM, Grisha Levit wrote: Avoid leaking ifs_chars on more return paths. Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.e

Re: [PATCH] readstr: do not clear undo list

On 5/27/24 7:56 PM, Grisha Levit wrote: The undo command fails if invoked via execute-named-command on a line from the history list: $ bash --norc -in <<< $'A\n\cPB\c_C' bash-5.3$ A bash-5.3$ AC $ bash --norc -in <<< $'A\n\cPB\exundo\nC' bash-5.3$ A bash-5.3$ ABC

Re: Bash has a stack overflow vulnerability

On 5/30/24 12:53 AM, B_M wrote: Hello, I have discovered a severe heap overflow vulnerability in Bash, which exists in both the latest and older versions. Attackers can craft payloads to elevate privileges or execute malicious code. Should I directly submit it to the CVE website, or should I send

Bash has a stack overflow vulnerability

Hello, I have discovered a severe heap overflow vulnerability in Bash, which exists in both the latest and older versions. Attackers can craft payloads to elevate privileges or execute malicious code. Should I directly submit it to the CVE website, or should I send it to you? If I send it to you, c