Re: Bash 5.2.21 segfaults when I feed it garbage
On 1/8/24 12:10 AM, Nathan Mills wrote: Bash Version: 5.2 Patch Level: bash-5.2-22-g4b0f8ba2 Release Status: master Description: Bash 5.2 segfaults when I run the following crashing input (See Repeat-By:). Thanks for the report and detailed diagnosis, and the reproducer. Your fix, unfortunately, introduces a number of memory leaks without changes to restore_parser_state and some other code paths. I think there's a simpler way to fix it in parse_compound_assignment and parse_string_to_word_list directly, and that change will be in the next devel branch push. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bash 5.2.0: Memory leak with $(
Jan 8, 2024, 09:23 by chet.ra...@case.edu: > > *** ../bash-5.2-patched/builtins/evalstring.c Tue Dec 13 12:53:21 2022 > --- builtins/evalstring.c Tue Nov 28 17:25:39 2023 > *** > *** 763,766 > --- 773,779 > if (fnp) > *fnp = fn; > + else > + free (fn); > + > return fd; > } > > That fixed the leak perfectly. Thank you! Do any of the other six patches in that report also apply to Bash 5.2?
Re: wait skips signals but first one
On 1/5/24 2:46 PM, Mykyta Dorokhin wrote: Bash Version: 5.1 Patch Level: 16 Release Status: release Description: I'm working on a custom project within the Yocto framework. After a recent build system update, the bash version updated to 5.1.16. Subsequently, I've noticed peculiar side effects related to using 'wait' and signals. Below is a script demonstrating the issue. The problem lies in the fact that, in the case of waiting on 'wait' in the script, only the first signal interrupts 'wait'; subsequent signals of the same type do not interrupt 'wait', and it remains blocked. I manually switched bash versions and compiled a table (bash version - Yocto version): 5.0.18 (dunfell): No issues 5.1.4 (hardknott): Has issues 5.1.8 (honister): Has issues 5.1.16 (kirkstone): Has issues 5.2.21 (master): Has issues Meanwhile, in my home desktop distribution, Ubuntu 22.04, I tested the same scenario, and everything works correctly; signals are processed as expected. My assumption is that the problem may be related to my Yocto build being intended for a 32-bit device, and perhaps the bug only manifests in this case. The only way I could see a potential problem was if you're using a 32-bit build on a 64-bit device. I consider this a significant issue. Could you confirm whether any testing has been conducted on 32-bit platforms, as it seems that everything works correctly on 64-bit desktops? I don't have any 32-bit platforms available for testing, but I have a hard time believing that it would make a difference. Like you, I can't reproduce it on the desktop platforms I have available right now. The bash devel git branch has fairly fine granularity. If you can automate the signal sending somewhat, maybe by having a child process send signals to $$, you could use your script and `git bisect' to find the commit where the behavior changed. bash-5.0 was frozen 12/31/2018, and bash-5.1 was frozen 12/14/2020, so that should get you started with the devel branch commits you want to inspect. http://git.savannah.gnu.org/cgit/bash.git/log/?h=devel -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
bash-4-2 issue
Hi, We see that bash throws the "Operation not permitted" error when doing chained pipe operation along with a debug trap. We set a debug trap here "my_debug" to save the terminal commands entered. The GNU bash, version used is 4.2. root@freescale-p2020ds:~/dir# ls -l | grep a | grep b | grep c -sh: child setpgid (4238 to 4232): Operation not permitted root@freescale-p2020ds:~/dir# trap trap -- '' TSTP trap -- '' TTIN trap -- '' TTOU trap -- 'my_debug' DEBUG root@freescale-p2020ds:~/dir# Platform: Linux 3.10 kernel on PPC target. It seems setpgid is failing because the process group of the pipeline does not exist at that time. This issue is not seen on bash version 4.4. The commit ( https://git.savannah.gnu.org/cgit/bash.git/commit/?h=bash-4.4=a0c0a00fc419b7bc08202a79134fcd5bc0427071) seems to have fixed it. I am looking to figure out the particular fix that fixed this issue from the above commit and to backport to bash4-2 version. Is it a known issue? Could you help to identify the change set that fixed the issue from the commit "a0c0a00fc419b"? Thanks in advance. Regards, Sam
Bash 5.2.21 segfaults when I feed it garbage
From: Nathan Mills
To: bug-bash@gnu.org
Subject: Bash 5.2.21 segfaults when I feed it garbage
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: clang-15.0.7
Compilation CFLAGS: -g -O2
uname output: Linux MSI 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5
21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Patch Level: bash-5.2-22-g4b0f8ba2
Release Status: master
Description:
Bash 5.2 segfaults when I run the following crashing input (See
Repeat-By:). It seems to be a use-after-free bug because Bash fills freed
memory with the byte 0xcf and the value of t->expander is
0xcfcfcfcfcfcfcfcf. t->expander should be either a valid pointer value or
NULL. Watching t->expander and then reverse-continuing twice shows that
that structure was freed by free_string_list, called by reset_parser. I
fixed the bug by
This is a parser save/restore state bug where it doesn't properly restore
the state of the parser after yyerror. yyerror calls reset_parser which
frees the pushed_string_list, but ps->pushed_strings still holds the old
linked list with the second item in the linked list being a dangling
pointer near the end of restore_parser_state in parse.y:6691.
This bug was found by compiling Bash 5.2 g4b0f8ba2 with AFL++ 4.09c in
Clang LTO mode (which was itself compiled with Clang 15.0.7), and running
afl-fuzz in Docker Desktop 24.0.6 in Windows 10. Then I double-checked to
make sure that the bug still exists when compiled without AFL++
instrumentation, and it does. The bug disappears when I apply the included
patch.
Reproducible every time with unpatched Bash, and never with the patch
applied.
0x7fdc78ce7550 in _start () from /lib64/ld-linux-x86-64.so.2
Missing separate debuginfos, use: zypper install
glibc-debuginfo-2.31-150300.63.1.x86_64
(rr) c
Continuing.
output_5.2-22-g4b0f8ba2/default/crashes/id:00,sig:11,src:005994+005483,time:12318097,execs:712991,op:splice,rep:8:
line 3: syntax error near unexpected token `|'
output_5.2-22-g4b0f8ba2/default/crashes/id:00,sig:11,src:005994+005483,time:12318097,execs:712991,op:splice,rep:8:
line 3: `(((F)
+=G=A9*F)
Y=([)]=�cw�l|YK?E<< �pt{{$[[expander->flags &= ~AL_BEINGEXPANDED;
Missing separate debuginfos, use: zypper install
libncurses6-debuginfo-6.1-15.5.20.1.x86_64
rr-debuginfo-5.6.0-bp155.3.8.x86_64
(rr) p t->expander
$1 = (alias_t *) 0xcfcfcfcfcfcfcfcf
(rr) bt
#0 0x5586164edfcc in pop_string () at
/usr/local/src/chet/src/bash/src/parse.y:1988
#1 0x5586164fb865 in shell_getc
(remove_quoted_newline=remove_quoted_newline@entry=1)
at /usr/local/src/chet/src/bash/src/parse.y:2667
#2 0x5586164f49b3 in read_token (command=0) at
/usr/local/src/chet/src/bash/src/parse.y:3418
#3 0x5586164e8fcf in yylex () at
/usr/local/src/chet/src/bash/src/parse.y:2905
#4 yyparse () at y.tab.c:1854
#5 0x5586164e89d4 in parse_command () at eval.c:348
#6 0x5586164e82f7 in read_command () at eval.c:392
#7 0x5586164e7d2b in reader_loop () at eval.c:139
#8 0x5586164e5307 in main (argc=2, argv=0x7fff657b6c38, env=) at shell.c:833
(rr) watch -l t->expander
Hardware watchpoint 1: -location t->expander
(rr) reverse-continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
pop_string () at /usr/local/src/chet/src/bash/src/parse.y:1988
1988t->expander->flags &= ~AL_BEINGEXPANDED;
(rr) reverse-continue\
Continuing.
Hardware watchpoint 1: -location t->expander
Old value = (alias_t *) 0xcfcfcfcfcfcfcfcf
New value = (alias_t *) 0x0
0x7f8fa6cd5422 in __memset_avx2_unaligned_erms () from /lib64/libc.so.6
(rr) bt
#0 0x7f8fa6cd5422 in __memset_avx2_unaligned_erms () from
/lib64/libc.so.6
#1 0x55a21abba0cd in internal_free (mem=0x55a21c97c910,
file=0x55a21abbada6 "/usr/local/src/chet/src/bash/src/parse.y",
line=2009, flags=) at malloc.c:1048
#2 0x55a21ab01f20 in free_string_list () at
/usr/local/src/chet/src/bash/src/parse.y:2009
#3 reset_parser () at /usr/local/src/chet/src/bash/src/parse.y:
#4 0x55a21ab098c4 in yyerror (msg=) at
/usr/local/src/chet/src/bash/src/parse.y:6127
#5 parse_compound_assignment (retlenp=retlenp@entry=0x7ffc7ff88f7c) at
/usr/local/src/chet/src/bash/src/parse.y:6526
#6 0x55a21ab0546c in read_token_word (character=61) at
/usr/local/src/chet/src/bash/src/parse.y:5168
#7 read_token (command=0) at /usr/local/src/chet/src/bash/src/parse.y:3610
#8 0x55a21aafeaff in yylex () at
/usr/local/src/chet/src/bash/src/parse.y:2905
#9 yyparse () at y.tab.c:1854
#10 0x55a21aafe78f in parse_command () at eval.c:348
#11 0x55a21aafe4d3 in read_command () at eval.c:392
#12 0x55a21aafe2b4 in reader_loop () at eval.c:139
#13 0x55a21aafcd20 in main (argc=2, argv=0x7ffc7ff8a198, env=) at shell.c:833
Repeat-By:
Run the following with Bash 5.2 after base64 decoding it:
KCgoKEYpCis9Rz1BGRkZORkZGQAZKhlGKQpZPShbKV09g2N3hmx8WUs/RTw8IL1wdHt7JFtbPEgp
Re: Bash 5.2.0: Memory leak with $(
On 1/7/24 12:59 AM, Grisha Levit wrote: On Sun, Jan 7, 2024, 00:26 pourko--- via Bug reports for the GNU Bourne Again SHell wrote: For demonstration, put a $( The bug is not present in bashes before 5.2.0. I believe this is fixed in (yet unreleased) Bash 5.3. See report [1] applied in [2]. [1]: https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00045.html [2]: https://git.savannah.gnu.org/cgit/bash.git/diff/builtins/evalstring.c?h=devel=81f7b44564cd1510788035cea7c59631865a7db2=1#n766 It's the change to open_redir_file that makes the difference, in case it's not clear from the diff. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bash 5.2.0: Memory leak with $(
On 1/7/24 1:17 AM, pourko--- via Bug reports for the GNU Bourne Again SHell wrote: [2]: > https://git.savannah.gnu.org/cgit/bash.git/diff/builtins/evalstring.c?h=devel=81f7b44564cd1510788035cea7c59631865a7db2=1#n766 Could we maybe get a patch for the 5.2 series? *** ../bash-5.2-patched/builtins/evalstring.c Tue Dec 13 12:53:21 2022 --- builtins/evalstring.c Tue Nov 28 17:25:39 2023 *** *** 763,766 --- 773,779 if (fnp) *fnp = fn; + else + free (fn); + return fd; } -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
