Re: Heap-buffer-overflow in read_token_word() when read element with -1 index

Hi Александр On Thu, 24 Apr 2025 at 03:30, Александр Ушаков wrote: > #define current_delimiter(ds) \ > (ds.delimiter_depth && !(ds.delimiter_depth - 1 < 0) ? > ds.delimiters[ds.delimiter_depth - 1] : 0) This seems unnecessarily complex; why not simply #define current_delimiter(ds) (ds.delim

Re: Heap-buffer-overflow in read_token_word() when read element with -1 index

On 4/23/25 1:37 PM, Grisha Levit wrote: On Wed, Apr 23, 2025, 11:40 Chet Ramey wrote: On 4/23/25 11:30 AM, Александр Ушаков wrote: I encountered an issue in Bash and would like to report it. buggyfile.txt is attached to the email. Steps to reproduce $ CC=clang-19 CFLAGS="-fsanitize=addres

Re: Heap-buffer-overflow in read_token_word() when read element with -1 index

On Wed, Apr 23, 2025, 11:40 Chet Ramey wrote: > > On 4/23/25 11:30 AM, Александр Ушаков wrote: > > > I encountered an issue in Bash and would like to report it. buggyfile.txt > > is attached to the email. > > > > Steps to reproduce > > > > $ CC=clang-19 CFLAGS="-fsanitize=address -g -O0" ./config

Re: Heap-buffer-overflow in read_token_word() when read element with -1 index

On 4/23/25 11:30 AM, Александр Ушаков wrote: I encountered an issue in Bash and would like to report it. buggyfile.txt is attached to the email. Steps to reproduce $ CC=clang-19 CFLAGS="-fsanitize=address -g -O0" ./configure --without-bash-malloc $ make $ cat crash1.txt | ./bash --norc --noe

Heap-buffer-overflow in read_token_word() when read element with -1 index

Expected Behaviour Any error messages without asan ERROR. Actual Behaviour ==349030==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5021a40e at pc 0x55711a6a bp 0x7fffcfb0 sp 0x7fffcfa8 ==READ of size 1 at 0x5021a40e thread T0 #0 0x55711a69 in read_token_word

Re: Heap-buffer-overflow in parse_matched_pair when push_delimiter (dstack, ch) macros opens up

On 4/20/25 2:45 PM, Александр Ушаков wrote: Dear Bash Maintainers, I encountered an issue in Bash and would like to report it. buggyfile.txt is attached to the email. The attached file is just a copy of bashbug. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

Heap-buffer-overflow in parse_matched_pair when push_delimiter (dstack, ch) macros opens up

Behaviour Any error messages without asan ERROR. Actual Behaviour ==139644==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x50202c6f at pc 0x5570f821 bp 0x7fff86b0 sp 0x7fff86a8 WRITE of size 1 at 0x50202c6f thread T0    #0 0x5570f820 in parse_matched_pair

Re: [PATCH 2/2] printf: fix heap buffer overflow in bexpand

On 8/29/24 10:22 AM, Andrey Kovalev wrote: In the loop, when iterating through the array, there was no check whether an element of the array goes beyond its limits. And with certain input data, there is an outflow from the array. Thanks for the report. This was fixed back in May, 2023, the resu

Re: [PATCH 1/2] printf: fix heap buffer overflow in printf_builtin

On 8/30/24 10:41 AM, Martin D Kealey wrote: Hi Andrei Ok, I see the problem. This fault is triggered when the format string has '%(' but is missing the closing ')' - so the entire remainder of the format string is tentatively recorded as the time-format substring. Yes. This line: if (

Re: [PATCH 1/2] printf: fix heap buffer overflow in printf_builtin

On 8/29/24 10:21 AM, Andrey Kovalev wrote: In the loop, when iterating through the array, there was no check whether an element of the array goes beyond its limits. And with certain input data, there is an outflow from the array. Thanks for the report. -- ``The lyf so short, the craft so long

Re: [PATCH 1/2] printf: fix heap buffer overflow in printf_builtin

> > Here is the ASAN trigger on the input data that I attached to this email: > > ==2==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x508009f8 at pc 0x55b1ce740ee0 bp 0x7fff5353bf90 sp 0x7fff5353bf88 > > READ of size 1 at 0x508009f8 thread T0 > >

Re: [PATCH 1/2] printf: fix heap buffer overflow in printf_builtin

branch, so I wrote a patch to fix it. Here is the ASAN trigger on the input data that I attached to this email: ==2==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x508009f8 at pc 0x55b1ce740ee0 bp 0x7fff5353bf90 sp 0x7fff5353bf88 READ of size 1 at 0x508009f8 thread T0     #0

Re: [PATCH 1/2] printf: fix heap buffer overflow in printf_builtin

On Aug 29 2024, Andrey Kovalev wrote: > - for (fmt = format; *fmt; fmt++) > + for (fmt = format; fmt - format < strlen(format); fmt++) How is that different (apart from turing a linear runtime into quadratic runtime)? -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint =

[PATCH 2/2] printf: fix heap buffer overflow in bexpand

In the loop, when iterating through the array, there was no check whether an element of the array goes beyond its limits. And with certain input data, there is an outflow from the array. --- builtins/printf.def | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtins/printf.de

[PATCH 1/2] printf: fix heap buffer overflow in printf_builtin

In the loop, when iterating through the array, there was no check whether an element of the array goes beyond its limits. And with certain input data, there is an outflow from the array. --- builtins/printf.def | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/builtins/prin

[PATCH 2/2] printf: fix heap buffer overflow in bexpand

In the loop, when iterating through the array, there was no check whether an element of the array goes beyond its limits. And with certain input data, there is an outflow from the array. --- builtins/printf.def | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtins/printf.de

Re: heap-buffer-overflow in finfo.c

On 8/24/23 1:23 PM, Grisha Levit wrote: $ enable finfo $ finfo -P '' . ERROR: AddressSanitizer: heap-buffer-overflow ... READ of size 1 at 0x003b09b8d4d1 thread T0 #0 0x6e45535088 in octal examples/loadables/finfo.c:104:9 Thanks for the reports. -- ``The lyf so short, the cra

heap-buffer-overflow in finfo.c

$ enable finfo $ finfo -P '' . ERROR: AddressSanitizer: heap-buffer-overflow ... READ of size 1 at 0x003b09b8d4d1 thread T0 #0 0x6e45535088 in octal examples/loadables/finfo.c:104:9 Could either fix up the octal function: diff --git a/examples/loadables/finfo.c b/examples/loadabl

Re: heap-buffer-overflow in history_expand

On 5/25/23 6:10 PM, Grisha Levit wrote: I noticed a couple of other bits missing from the patch as applied though. (The first because pending_bytes_length is not defined without HANDLE_MULTIBYTE, the second to have quoted insert work without a negative argument). Thanks for the update. Chet

Re: heap-buffer-overflow in history_expand

On Mon, May 1, 2023 at 11:48 AM Chet Ramey wrote: > Yes, I concluded the same thing. Thanks for the patch. I have one question > about the change to rl_insert: why overwrite any return value from the > initial call to _rl_insert_char by setting r back to 0? What if the initial > value of C starts

Re: heap-buffer-overflow in history_expand

On 4/30/23 5:03 AM, Grisha Levit wrote: On Sat, Apr 29, 2023, 14:02 Chet Ramey > wrote: On 4/28/23 9:28 PM, Grisha Levit wrote: > Piping input that simply ends in an leading byte doesn't trigger the issue > -- that byte byte don't seem to make it int

Re: heap-buffer-overflow in history_expand

On Sat, Apr 29, 2023, 14:02 Chet Ramey wrote: > On 4/28/23 9:28 PM, Grisha Levit wrote: > > Piping input that simply ends in an leading byte doesn't trigger the > issue > > -- that byte byte don't seem to make it into the input line. > > > > This is a bit off topic, but I don't really understand

Re: heap-buffer-overflow in history_expand

On 4/28/23 9:28 PM, Grisha Levit wrote: On Fri, Apr 28, 2023, 11:35 Chet Ramey > wrote: On 4/24/23 1:40 AM, Grisha Levit wrote: > The history expansion code can end up reading past the end of the > input line buffer if the line ends with an invalid mu

Re: heap-buffer-overflow in history_expand

On Fri, Apr 28, 2023, 11:35 Chet Ramey wrote: > On 4/24/23 1:40 AM, Grisha Levit wrote: > > The history expansion code can end up reading past the end of the > > input line buffer if the line ends with an invalid multibyte sequence: > > Thanks for the report. You mean an incomplete multibyte char

Re: heap-buffer-overflow in history_expand

On 4/24/23 1:40 AM, Grisha Levit wrote: The history expansion code can end up reading past the end of the input line buffer if the line ends with an invalid multibyte sequence: Thanks for the report. You mean an incomplete multibyte character, I think. Chet -- ``The lyf so short, the craft so

heap-buffer-overflow in history_expand

The history expansion code can end up reading past the end of the input line buffer if the line ends with an invalid multibyte sequence: bash --norc -in <<<$'X\n\e238Y!!\xC2\xC2' ERROR: AddressSanitizer: heap-buffer-overflow READ of size 1 at 0x000108b48400 thread T0

Re: global-buffer-overflow in parse.y

On 3/16/23 6:10 PM, Grisha Levit wrote: On Mon, Mar 6, 2023 at 9:16 AM Chet Ramey wrote: Thanks for the report. It's the specific combination of `if' and the `((' command that causes the problem. Looks like same thing also happens when `if' is followed by a newline Thanks for the report. -

Re: global-buffer-overflow in parse.y

On Mon, Mar 6, 2023 at 9:16 AM Chet Ramey wrote: > Thanks for the report. It's the specific combination of `if' and the `((' > command that causes the problem. Looks like same thing also happens when `if' is followed by a newline ./bash -c $'case $LINENO in 0) if\n:; then echo FAIL; fi esac' bas

Re: global-buffer-overflow in parse.y

or parse.y:974:82 in = ==52960==ERROR: AddressSanitizer: global-buffer-overflow READ of size 4 at 0x000100cf26dc thread T0 #0 0x1004b63c8 in yyparse parse.y:974 Thanks for the report. It's the specific combination of `if' and the `((' command that causes the problem

global-buffer-overflow in parse.y

= ==52960==ERROR: AddressSanitizer: global-buffer-overflow READ of size 4 at 0x000100cf26dc thread T0 #0 0x1004b63c8 in yyparse parse.y:974 $ ./bash -c 'case x in x) if ((1)); then :; fi esac' parse.y:979:82: runtime error: index -1 out of bounds for type 'int[257]' SUMMARY: Undefi

Re: Buffer overflow in bash's readline

On 9/23/22 3:24 PM, srobert...@peratonlabs.com wrote: Bash Version: 5.1 Patch Level: 8 Release Status: release Description: Repeatable buffer overflow core-dump in bash's readline due to rl_forced_update_display trying to zeroize a string that is not NUL termi

Buffer overflow in bash's readline

:09 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 5.1 Patch Level: 8 Release Status: release Description: Repeatable buffer overflow core-dump in bash's readline due to rl_forced_update_display trying to zeroize a string th

Re: Heap-buffer-overflow in valid_parameter_transform

On 8/31/22 3:34 PM, Ivan Kapranov wrote: Are you sure? The patch i have attached fixes a buffer overflow if the xform is a single character string. The xform is always a single-character string. xform[1] had better be the '\0' that terminates it. If it's not, the xform is i

Re: Heap-buffer-overflow in valid_parameter_transform

Are you sure? The patch i have attached fixes a buffer overflow if the xform is a single character string. 31.08.2022, 22:26, "Chet Ramey" : On 8/30/22 1:02 PM, Иван Капранов wrote: Configuration Information [Automatically generated, do not

Re: Heap-buffer-overflow in valid_parameter_transform

ase Status: release Hi! I was fuzzing bash with AFL++ and found heap-buffer-overflow in valid_parameter_transform function. Description: ASAN report: ==3430898==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602018 b1 at pc 0x563102ad26cf bp 0x7ffc38fef8d0

Re: Heap-buffer-overflow in valid_parameter_transform

On 8/30/22 1:02 PM, Иван Капранов wrote: Repeat-By: 1. Build bash with asan 2. Run with AFL++ crafted input (in attachment) There's no attachment. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech

Heap-buffer-overflow in valid_parameter_transform

AFL++ and found heap-buffer-overflow in valid_parameter_transform function. Description: ASAN report: ==3430898==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602018 b1 at pc 0x563102ad26cf bp 0x7ffc38fef8d0 sp 0x7ffc38fef8c8 READ of size 1 at 0x602018b1 thread T0

Re: Buffer Overflow

On Tue, Apr 12, 2022 at 02:45:15PM -0400, Sergio Fuentes wrote: > Please, run the following 3 commands to reproduce the bug: > > echo '. ./poc.sh' > poc.sh > chmod +x poc.sh > bash -c './poc.sh' You're performing an infinite recursion. Eventually, you'll overflow the stack, and bash will crash.

Re: Buffer Overflow

On Tue, Apr 12, 2022, 3:18 PM Sergio Fuentes < fuentes.sergio.nov2...@gmail.com> wrote: > Hello, > > Please, run the following 3 commands to reproduce the bug: > > echo '. ./poc.sh' > poc.sh > chmod +x poc.sh > bash -c './poc.sh' > > The backtrace from gdb: > gdb /bin/bash core > ... > Program ter

Re: Buffer Overflow

On 4/12/22 2:45 PM, Sergio Fuentes wrote: > Hello, > > Please, run the following 3 commands to reproduce the bug: > > echo '. ./poc.sh' > poc.sh > chmod +x poc.sh > bash -c './poc.sh' You've created infinite recursion using `.' and run yourself out of stack space. This isn't a bug. You can set

Buffer Overflow

Hello, Please, run the following 3 commands to reproduce the bug: echo '. ./poc.sh' > poc.sh chmod +x poc.sh bash -c './poc.sh' The backtrace from gdb: gdb /bin/bash core ... Program terminated with signal SIGSEGV, Segmentation fault. #0 0x5612fcdece65 in yyparse () (gdb) bt #0 0x5612f

Re: [PATCH] unwind_prot.c: Avoid buffer overflow

On 6/27/20 5:14 PM, Jessica Clarke wrote: > In unwind_protect_mem_internal, we must make sure to allocate at least a > full UNWIND_ELT, even if the required size for desired_setting is less > than the remaining padding in UNWIND_ELT. Otherwise when we come to > memset it with 0xdf in unwind_frame_d

[PATCH] unwind_prot.c: Avoid buffer overflow

. Moreover on CHERI-RISC-V, pointers are replaced with capabilities, 16-byte fat pointers, and the padding now ends up being 12 bytes, violating this assumption, but also trapping on this detected buffer overflow by virtue of its fine-grained bounds. --- unwind_prot.c | 2 ++ 1 file changed, 2 insertions

Re: possible buffer overflow by bad translation

On 9/15/19 2:24 PM, Roland Illig wrote: > From siglist.c: > > sys_siglist[i] = > (char *)xmalloc (10 + strlen (_("Unknown Signal #"))); > > sprintf (sys_siglist[i], _("Unknown Signal #%d"), i); I'll figure something out. This code is used in exceedingly rare circumstanc

possible buffer overflow by bad translation

>From siglist.c: sys_siglist[i] = (char *)xmalloc (10 + strlen (_("Unknown Signal #"))); sprintf (sys_siglist[i], _("Unknown Signal #%d"), i); If the translator doesn't look at the code using these two messages, they may be translated in a totally different way. L

Buffer overflow in string_extract_double_quoted - subst.c

read -e < dispose_word' hi "��$$( TRACE: pid 29276: xparse_dolparen:0: base[5] != RPAREN (40), base = `"��$$( ' TRACE: pid 29276: xparse_dolparen:0: *indp (5) < orig_ind (6), orig_string = ` ' = ==29276==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602

Re: AddressSanitizer: heap-buffer-overflow in rl_kill_text

;> >> >> ==11018==ERROR: AddressSanitizer: heap-buffer-overflow on address >> 0x6070ccc0 at pc 0x559bb60f1be7 bp 0x7ffc36ec8710 sp 0x7ffc36ec8708 >> READ of size 8 at 0x6070ccc0 thread T0 >> #0 0x559bb60f1be6 in _rl_copy_to_kill_ring >> (/home

Re: AddressSanitizer: global-buffer-overflow in rl_filename_completion_function

t;> >> >> ==1098==ERROR: AddressSanitizer: global-buffer-overflow on address >> 0x55e61a6b4c5c at pc 0x55e61a3426ca bp 0x7fff1820a300 sp 0x7fff1820a2f8 >> READ of size 4 at 0x55e61a6b4c5c thread T0 >> #0 0x55e61a3426c9 in bash_dequote_filename >> (/home/dualbus/sr

Re: AddressSanitizer: heap-buffer-overflow in rl_tilde_expand

gt;> >> >> ==472==ERROR: AddressSanitizer: heap-buffer-overflow on address >> 0x6110977f at pc 0x562befba4a14 bp 0x7ffdee172bb0 sp 0x7ffdee172ba8 >> READ of size 1 at 0x6110977f thread T0 >> #0 0x562befba4a13 in rl_tilde_expand >> (/home/dualbus/src/gnu/bash-b

Re: AddressSanitizer: heap-buffer-overflow in rl_delete

t;> >> >> ==1736==ERROR: AddressSanitizer: heap-buffer-overflow on address >> 0x61109880 at pc 0x7f464da3a063 bp 0x7ffe86032fe0 sp 0x7ffe86032790 >> READ of size 115 at 0x61109880 thread T0 >> #0 0x7f464da3a062 (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062) &

Re: AddressSanitizer: heap-buffer-overflow in rl_kill_text

On Thu, Jun 15, 2017 at 09:42:41AM -0500, Eduardo Bustamante wrote: > Found by fuzzing `read -e' with AFL. The stacktrace reported by Address > Sanitizer is followed by the base64 encoded crashing input. > > > ==11018==ERROR: AddressSanitizer: heap-buffer-overflow on address

Re: AddressSanitizer: heap-buffer-overflow in rl_tilde_expand

On Thu, Jun 15, 2017 at 09:39:09AM -0500, Eduardo Bustamante wrote: > Found by fuzzing `read -e' with AFL. The stacktrace reported by Address > Sanitizer is followed by the base64 encoded crashing input. > > > ==472==ERROR: AddressSanitizer: heap-buffer-overflow on address

Re: AddressSanitizer: global-buffer-overflow in rl_filename_completion_function

On Thu, Jun 15, 2017 at 09:41:08AM -0500, Eduardo Bustamante wrote: > Found by fuzzing `read -e' with AFL. The stacktrace reported by Address > Sanitizer is followed by the base64 encoded crashing input. > > > ==1098==ERROR: AddressSanitizer: global-buffer-overflow on addre

Re: AddressSanitizer: heap-buffer-overflow in rl_delete

On Thu, Jun 15, 2017 at 09:36:58AM -0500, Eduardo Bustamante wrote: > Found by fuzzing `read -e' with AFL. The stacktrace reported by Address > Sanitizer is followed by the base64 encoded crashing input. > > > ==1736==ERROR: AddressSanitizer: heap-buffer-overflow on address

AddressSanitizer: heap-buffer-overflow in shell_expand_line

Found by fuzzing `read -e' with AFL. The stacktrace reported by Address Sanitizer is followed by the base64 encoded crashing input. ==7938==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60c0bd00 at pc 0x55ae5ef673f0 bp 0x7ffd16140ec0 sp 0x7ffd16140eb8 WRITE of size

AddressSanitizer: heap-buffer-overflow in rl_kill_text

Found by fuzzing `read -e' with AFL. The stacktrace reported by Address Sanitizer is followed by the base64 encoded crashing input. ==11018==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6070ccc0 at pc 0x559bb60f1be7 bp 0x7ffc36ec8710 sp 0x7ffc36ec8708 READ of size

AddressSanitizer: heap-buffer-overflow in rl_search_history

Found by fuzzing `read -e' with AFL. The stacktrace reported by Address Sanitizer is followed by the base64 encoded crashing input. ==15910==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6110977f at pc 0x55794384fd88 bp 0x7ffd35b10720 sp 0x7ffd35b10718 READ of size

AddressSanitizer: global-buffer-overflow in rl_filename_completion_function

Found by fuzzing `read -e' with AFL. The stacktrace reported by Address Sanitizer is followed by the base64 encoded crashing input. ==1098==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55e61a6b4c5c at pc 0x55e61a3426ca bp 0x7fff1820a300 sp 0x7fff1820a2f8 READ of size

AddressSanitizer: heap-buffer-overflow in rl_tilde_expand

Found by fuzzing `read -e' with AFL. The stacktrace reported by Address Sanitizer is followed by the base64 encoded crashing input. ==472==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6110977f at pc 0x562befba4a14 bp 0x7ffdee172bb0 sp 0x7ffdee172ba8 READ of size

AddressSanitizer: heap-buffer-overflow in rl_delete

Found by fuzzing `read -e' with AFL. The stacktrace reported by Address Sanitizer is followed by the base64 encoded crashing input. ==1736==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61109880 at pc 0x7f464da3a063 bp 0x7ffe86032fe0 sp 0x7ffe86032790 READ of size 1

Re: AddressSanitizer: heap-buffer-overflow _rl_find_prev_mbchar_internal / expand_prompt

On 6/14/17 11:19 AM, Eduardo Bustamante wrote: > On Tue, Jun 13, 2017 at 04:30:23PM -0400, Chet Ramey wrote: > [...] >> I can't reproduce it with asan or without on Mac OS X. I'll look around >> for a Linux system with asan to run it on. > > All these inputs seem to trigger the same problem. You'l

Re: AddressSanitizer: heap-buffer-overflow _rl_find_prev_mbchar_internal / expand_prompt

ed by ASAN first, and then the corresponding input base64 encoded. ==12445==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d0c159 at pc 0x7f0b81373063 bp 0x7ffc11229040 sp 0x7ffc112287f0 READ of size 138 at 0x60d0c159 thread T0 #0 0x7f0b81373062 (/usr/lib/x86_64-linux-gnu

Re: AddressSanitizer: heap-buffer-overflow _rl_find_prev_mbchar_internal / expand_prompt

On Tue, Jun 13, 2017 at 3:30 PM, Chet Ramey wrote: [...] > I can't reproduce it with asan or without on Mac OS X. I'll look around > for a Linux system with asan to run it on. I had to use these exact same environment variables, otherwise the out of bounds read wouldn't happen. I'm not sure if it

Re: AddressSanitizer: heap-buffer-overflow _rl_find_prev_mbchar_internal / expand_prompt

On 6/13/17 11:14 AM, Eduardo Bustamante wrote: > It seems like this is another case of strlen reading too much. I can't reproduce it with asan or without on Mac OS X. I'll look around for a Linux system with asan to run it on. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

AddressSanitizer: heap-buffer-overflow _rl_find_prev_mbchar_internal / expand_prompt

ash-fuzzing/read-readline/output/10/crashes/id:11,sig:06,src:001239+003201,op:splice,rep:2 > /dev/null 2>&1 Aborted (core dumped) dualbus@debian:~/src/gnu/bash-build$ cat stacktrace = ==26129==ERROR: AddressSanitize

Re: AddressSanitizer: heap-buffer-overflow lib/readline/bind.c:437 in rl_translate_keyseq

On 5/2/17 10:22 AM, Eduardo Bustamante wrote: The valgrind issue might be related to the false positive issue from a couple of weeks ago, but it really doesn't matter. The bash malloc severely confuses valgrind. > I think this is the fix: > > dualbus@debian:~/src/gnu/bash$ git diff > diff --git

Re: AddressSanitizer: heap-buffer-overflow lib/readline/bind.c:437 in rl_translate_keyseq

On Tue, May 2, 2017 at 9:04 AM, Chet Ramey wrote: [...] dualbus@debian:~/src/gnu/bash$ valgrind --leak-check=full ./bash ==30183== Memcheck, a memory error detector ==30183== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==30183== Using Valgrind-3.12.0.SVN and LibVEX; rerun with

Re: AddressSanitizer: heap-buffer-overflow lib/readline/bind.c:437 in rl_translate_keyseq

On 5/2/17 1:22 AM, Eduardo Bustamante wrote: > bind '\xx":""' chet(1)$ valgrind ./bash ==8686== Memcheck, a memory error detector ==8686== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==8686== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==8686== Command: ./

Re: AddressSanitizer: heap-buffer-overflow lib/readline/bind.c:437 in rl_translate_keyseq

On Mon, May 1, 2017 at 11:58 PM, Eduardo Bustamante wrote: > Thanks, the latest commit no longer crashes on any of the malformed input > files. > > There's still a memory leak I hadn't noticed before: > [...] > bash-4.4$ bind '\xx":""' Actually, this one is shorter: bind '\:""' rl_translate_

Re: AddressSanitizer: heap-buffer-overflow lib/readline/bind.c:437 in rl_translate_keyseq

Thanks, the latest commit no longer crashes on any of the malformed input files. There's still a memory leak I hadn't noticed before: dualbus@debian:~/src/gnu/bash$ ./bash bash-4.4$ bind '\xx":""' bash-4.4$ exit = ==27221==ERROR: Le

Re: AddressSanitizer: heap-buffer-overflow lib/readline/bind.c:437 in rl_translate_keyseq

On Thu, Apr 27, 2017 at 2:35 PM, Chet Ramey wrote: [...] > Thanks for the report. This was an easy fix. You must be fuzzing > readline's key sequence parser. Yes. I'm currently trying a few approaches. I got this crash from: afl-fuzz -i i1/ -o o1/ -- ./bash/bash --noprofile --norc -ic 'bind -f

Re: AddressSanitizer: heap-buffer-overflow lib/readline/bind.c:437 in rl_translate_keyseq

On 4/27/17 8:02 AM, Eduardo Bustamante wrote: > dualbus@debian:~/src/gnu/bash$ xxd inputrc > : 225c 432d 2230 3030 200a "\C-"000 . Thanks for the report. This was an easy fix. You must be fuzzing readline's key sequence parser. -- ``The lyf so short, the craft so long to

AddressSanitizer: heap-buffer-overflow lib/readline/bind.c:437 in rl_translate_keyseq

OR: AddressSanitizer: heap-buffer-overflow on address 0x60209bb9 at pc 0x5628fdaa420b bp 0x7ffcde1bef40 sp 0x7ffcde1bef38 READ of size 1 at 0x60209bb9 thread T0 #0 0x5628fdaa420a in rl_translate_keyseq /home/dualbus/src/gnu/bash/lib/readline/bind.c:437 #1 0x5628fdaa2934 in rl_generic_bi

Re: Malicious translation file can cause buffer overflow

r could set the > > LANGUAGE variable to point to a malicious translation file that has > > translations that are longer than 64-bytes for these strings to create > > a buffer overflow. > > > > Since LANGUAGE is passed unchanged by sudo this might be usable for > > privil

Re: Malicious translation file can cause buffer overflow

ot;Done(%d)" and "Exit %d" > in jobs.c are copied to a static allocated buffer. A user could set the > LANGUAGE variable to point to a malicious translation file that has > translations that are longer than 64-bytes for these strings to create > a buffer overflow. > > Since

Re: Malicious translation file can cause buffer overflow

d buffer. A user could set the > LANGUAGE variable to point to a malicious translation file that has > translations that are longer than 64-bytes for these strings to create > a buffer overflow. > > Since LANGUAGE is passed unchanged by sudo this might be usable for > p

Re: bash buffer overflow in handling locale environment variables

On 4/30/15 4:59 PM, Chet Ramey wrote: >> Fix: >> Use strncpy() in place of strcpy() in lib/sh/unicode.c: >> >> --- /tmp/bash-4.3.30/lib/sh/unicode.c 2014-01-30 21:47:19.0 + >> +++ ./bash-4.3.30/lib/sh/unicode.c 2015-04-30 18:03:42.300340729 + >> @@ -78,7 +78,8 @@ >>s =

Malicious translation file can cause buffer overflow

ous translation file that has translations that are longer than 64-bytes for these strings to create a buffer overflow. Since LANGUAGE is passed unchanged by sudo this might be usable for privilege escalation. Repeat-By

Re: bash buffer overflow in handling locale environment variables

On 4/30/15 2:13 PM, Trammell Hudson wrote: > Bash Version: 4.3 > Patch Level: 30 > Release Status: release > > Description: > Overly long LC_ALL or LC_CTYPE variables can cause a buffer overflow > in converting 32-bit unicode characters. The stub_charset() function &g

Re: bash buffer overflow in handling locale environment variables

2015-04-30 18:13:48 +, Trammell Hudson: [...] > Overly long LC_ALL or LC_CTYPE variables can cause a buffer overflow > in converting 32-bit unicode characters. The stub_charset() function > calls strcpy() into a static 40-byte buffer for the charset, which > can be overflowed if

bash buffer overflow in handling locale environment variables

64-unknown-linux-gnu Bash Version: 4.3 Patch Level: 30 Release Status: release Description: Overly long LC_ALL or LC_CTYPE variables can cause a buffer overflow in converting 32-bit unicode characters. The stub_charset() function calls strcpy() into a static 40-byte buffer for the charset, which can

Re: buffer overflow errors

> Description: > Log files are showing an increased level of buffer overflows from common > CLI usage and scripts that previously did not result in excessive overflows > being passed. Can you show us a sample of these log files? Also the scripts that are causing the issue.

Re: buffer overflow errors

On 1/3/15 6:50 PM, Smokey Mtn Digital Hams wrote: > Bash Version: 4.3 > Patch Level: 11 > Release Status: release > > Description: > Log files are showing an increased level of buffer overflows from common > CLI usage and scripts that previously did not result in excessive overflows > being passe

buffer overflow errors

t in excessive overflows being passed. Repeat-By: Mostly this is from interactive CLI usage and commands passed from well written GUI scripts (mostly py). Some bash scripts are involved. The same scripts passed to zsh (edited appropriately) do not result in this level of buffer overflow. Fix: When I

Re: Buffer overflow bug in Bash

Ben Okopnik writes: > ./borked1: line 6: n/core-default.xml: expression recursion level exceeded > (error token is "n/core-default.xml") ${foo[n/core-default.xml]} tries to expand n first, which yields n/core-default.xml, rinse and repeat. > ./borked2: line 6: on/core-default.xml: division by 0

Buffer overflow bug in Bash

Hi - Here's a couple of scripts, stripped down to bare bones and tested on several recent bash versions; both cause a crash, with the following errors in all cases: ./borked1: line 6: n/core-default.xml: expression recursion level exceeded (error token is "n/core-default.xml") ./borked2: line 6:

Re: Bug in shell: buffer overflow.

I read the manual hastily. Sorry for message and thank you for perfect answer.

Re: Bug in shell: buffer overflow.

On my 32-bit system in Bash: $ printf '%u\n' -1 18446744073709551615 $ echo $((2**63-1)) 9223372036854775807 $ echo $((2**63)) -9223372036854775808 On Sat, Jan 1, 2011 at 11:48 AM, Stephane CHAZELAS wrote: > 2010-12-31, 11:33(-07), Bob Proulx: > [...] >> Your expressions above are overflowing th

Re: Bug in shell: buffer overflow.

Stephane CHAZELAS wrote: > Bob Proulx wrote: > [...] > > Your expressions above are overflowing the value of your system's > > maximum integer size. You can read the system's maximum integer size > > using getconf. > > > > $ getconf INT_MAX > > 2147483647 > [...] > > POSIX requires that arith

Re: Bug in shell: buffer overflow.

2010-12-31, 11:33(-07), Bob Proulx: [...] > Your expressions above are overflowing the value of your system's > maximum integer size. You can read the system's maximum integer size > using getconf. > > $ getconf INT_MAX > 2147483647 [...] POSIX requires that arithmetic expansion be using at l

Re: Bug in shell: buffer overflow.

n...@lavabit.com wrote: > echo $((256**8)) > echo $((72057594037927936*128)) > echo $((1)) > etc. Unless great effort is made to perform math in arbitrary precision http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic all computer

Bug in shell: buffer overflow.

Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/us uname output: Linux slax 2.6.2