Troubles with autocompletion of filenames with square brackets
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I./include -I. -I./include -I./lib
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
-DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin'
-DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout'
-DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -march=corei7-avx -O2 -pipe
-fomit-frame-pointer --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=6144
uname output: Linux home 3.16.6-geek-i5 #11 SMP PREEMPT Fri Jul 3 19:54:14 MSK
2015 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.3
Patch Level: 39
Release Status: release
Description:
Autocompletion fails for files starting with an opening square bracket
and having closing bracket somewhere in the filename.
Repeat-By:
$ mkdir temp && cd temp
$ mkdir -p one/{\[bad\]\ folder,\[yet\]\ another\ bad\ folder}
Now try
$ cd one# cd one/\[ â should appear
$ mkdir -p \[one\]/{\[bad\]\ folder,\[yet\]\ another\ bad\ folder}
Type
$ cd [ # cd \[one\]/ â should appear
$ cd \[one\]/â further completions do not work
$ mkdir -p \[two\]/{\[bad\]\ folder,\[yet\]\ another\ bad\ folder}
$ cd [ # cd \[ â should appear
$ cd \[t # â doesnât work.
$ cd \[tw # â doesnât work.
$ cd \[two # â doesnât work.
$ cd \[two] # â doesnât work.
$ cd \[two\] # â doesnât work.
But if you type
$ cd [two # cd \[two\]/ â should appear
Surprise â this works! Howeverâ¦
$ cd \[two\]/ # â no further completions work :(
Fix:
[Description of how to fix the problem. If you don't know a
fix for the problem, don't include this section.]
Bash-4.4-alpha available for FTP
The first alpha release of bash-4.4 is now available with the URL
ftp://ftp.cwru.edu/pub/bash/bash-4.4-alpha.tar.gz
This tar file includes the formatted documentation (you should be able to
generate updated versions yourself).
This release fixes many outstanding bugs in bash-4.3 and introduces several
new features. The most significant bug fixes are the remaining changes to
reworking of signal handling to avoid running signal and trap handlers in a
signal handler context. There are also several changes dealing with variables
that have been given attributes but not values, which means they are
technically unset.
All of the released patches for the shellshock vulnerability, and several
other related changes, are included in bash-4.4.
The most notable new features are mapfile's ability to use an arbitrary
record delimiter, a --help option available for nearly all builtins, a
new family of ${parameter@spec} expansions that transform the value of
`parameter', the `local' builtin's ability to save and restore the state
of the single-letter shell option flags around function calls, and a new
EXECIGNORE variable, which adds the ability to specify names that should
be ignored when searching for commands.
There are a few incompatible changes between bash-4.3 and bash-4.4. Bash
now retains the exit status only of asynchronous jobs, as opposed to all
jobs. This means that it is not possible to use `wait' to retrieve the
status of a previously-completed synchronous command. Bash no longer
attempts to perform compound assignment if a variable expansion on the
right-hand side of an assignment statement to `declare' or `local' has the
form of a compound assignment. There are other changes to compound array
assignments used as arguments to the `declare' and `local' builtins, but
those should be backwards compatible, albeit with warning messages about
deprecated constructs.
`bashbug' may be used to report bugs with this version. It will send
mail to c...@po.cwru.edu if the shell's `release status' is alpha or
beta.
As always, thanks for your help.
Chet
+== CHANGES ==+
This document details the changes between this version, bash-4.4-alpha, and
the previous version, bash-4.3-release.
1. Changes to Bash
a. A bug that caused pipelines to be corrupted while running the DEBUG trap
was fixed.
b. A bug that accidentally omitted the `-R' unary operator from `test' was
fixed.
c. A bug that could cause the shell to not restore the terminal's process
group on shell exit was fixed.
d. Several changes were made to programmable completion to accommodate
assumptions made by the bash-completion package.
e. Bash no longer inhibits C-style escape processing ($'...') while performing
pattern substitution word expansions.
f. Fixed a bug that caused `return' executed from a trap handler to use the
wrong return status when one was not supplied as an argument.
g. In Posix mode, defining a function with the same name as a special
builtin is now an error, fatal only when the shell is not interactive.
h. Fixed a bug that caused compound array assignments to discard unset or null
variables used as subscripts, thereby making it appear as if the index was
not present.
i. Fixed a bug that caused extended glob patterns to incorrectly match
filenames with a leading `.'.
j. Fixed a bug involving sign extension when reallocating the input line
after a history expansion, causing segmentation faults.
k. Bash now does a better job at identifying syntax errors during word
completion and tailoring completion appropriately.
l. Bash now uses the current locale's decimal point in comamnd timing output.
m. Fixed a bug that caused segmentation faults while reading here documents if
PS2 contains a command substitution.
n. There are several changes to how $@ is expanded when unquoted but in a
context where word splitting is not performed (e.g., on the rhs of an
assignment or in a conditional command).
o. Bash now quotes command hash table entries that contain shell metacharacters
when displaying hash table contents.
p. Fixed a potential file descriptor leak when dup2() fails while performing a
redirection.
q. Fixed a bug that caused directory names evaluated during word completion to
be dequoted twice.
r. Fixed several bugs which could result in indirect variable expansion and
namerefs creating variables with invalid names or referencing variables
set to the empty string.
s. Fixed a bug that caused bash to not expand $0 in word expansions where it
should.
t. Fixed a bug that caused bash to perform process substitution if <(
appeared inside an arithmetic context.
u. Fixed a bug in extglob pattern parsing that caused slashes in the pattern
to be confused as directory names.
v. Fixed several bugs with treatment of invisible variables (variables with
attributes that are unset because they have never b
problem with local -
Using local - calls set_ignoreeof() when unwinding "function_calling". As a result, you have to press ^D 10 times to exit the shell. Anyway, $IGNOREEOF is not changed and shopt -o ignoreeof reports off. I'm attaching the relevant part of a backtrace from gdb. --- xoxo iza gdb-trace Description: Binary data
Re: Another out of bounds heap read in bash completion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/6/15 6:46 PM, Hanno Böck wrote:
> Hi,
>
> With Address Sanitizer I discovered another out of bounds read issue in
> bash. This is different from the issue I recently reported here and
> for which Chet already provided a patch:
> https://lists.gnu.org/archive/html/bug-bash/2015-06/msg00089.html
>
> To reproduce:
> a) compile bash with CFLAGS="-fsanitize=address -g"
> b) type in a=/ a
> c) go back with the cursor behind the backslash and press tab
Thanks for the report. I've attached a patch that should address the
problem. It's not in bash-4.4-alpha.
Chet
- --
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iEYEARECAAYFAlWgDY8ACgkQu1hp8GTqdKtyOgCfXOaZfcweBw37AI0N4mnFW/Rz
gj4AoJYpm34tn/7lg+ChxV3TDq0WlTQl
=+rN7
-END PGP SIGNATURE-
*** ../bash-4.4-alpha/bashline.c 2015-06-23 14:35:10.0 -0400
--- bashline.c 2015-07-07 15:17:58.0 -0400
***
*** 1524,1527
--- 1524,1528
os = start;
n = 0;
+ was_assignment = 0;
s = find_cmd_start (os);
e = find_cmd_end (end);
***
*** 1534,1537
--- 1535,1544
break;
}
+ /* Or past point if point is within an assignment statement */
+ else if (was_assignment && s > rl_point)
+ {
+ s1 = s = e1;
+ break;
+ }
/* Skip over assignment statements preceding a command name. If we
don't find a command name at all, we can perform command name
Re: Another out of bounds heap read in bash completion
Hi Chet, On Fri, 10 Jul 2015 14:23:25 -0400 Chet Ramey wrote: > > To reproduce: > > a) compile bash with CFLAGS="-fsanitize=address -g" > > b) type in a=/ a > > c) go back with the cursor behind the backslash and press tab > > Thanks for the report. I've attached a patch that should address the > problem. It's not in bash-4.4-alpha. Can confirm the patch fixes the issue. However in 4.4 alpha I still get an asan error. However the stack trace is different. Here's the asan message on 4.4 alpha: ==5999==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60202d6f at pc 0x5ca2b8 bp 0x7fffc9d75240 sp 0x7fffc9d75230 READ of size 1 at 0x60202d6f thread T0 #0 0x5ca2b7 in printable_part /mnt/ram/bash-4.4-alpha/lib/readline/complete.c:738 #1 0x5ce776 in rl_display_match_list /mnt/ram/bash-4.4-alpha/lib/readline/complete.c:1571 #2 0x5cf358 in display_matches /mnt/ram/bash-4.4-alpha/lib/readline/complete.c:1753 #3 0x5d1448 in rl_complete_internal /mnt/ram/bash-4.4-alpha/lib/readline/complete.c:2124 #4 0x5c986a in rl_complete /mnt/ram/bash-4.4-alpha/lib/readline/complete.c:431 #5 0x5b7457 in _rl_dispatch_subseq /mnt/ram/bash-4.4-alpha/lib/readline/readline.c:860 #6 0x5b7032 in _rl_dispatch /mnt/ram/bash-4.4-alpha/lib/readline/readline.c:803 #7 0x5b683d in readline_internal_char /mnt/ram/bash-4.4-alpha/lib/readline/readline.c:630 #8 0x5b68cd in readline_internal_charloop /mnt/ram/bash-4.4-alpha/lib/readline/readline.c:657 #9 0x5b68f6 in readline_internal /mnt/ram/bash-4.4-alpha/lib/readline/readline.c:671 #10 0x5b5f1e in readline /mnt/ram/bash-4.4-alpha/lib/readline/readline.c:376 #11 0x42ea53 in yy_readline_get /usr/homes/chet/src/bash/src/parse.y:1452 #12 0x42e8ff in yy_getc /usr/homes/chet/src/bash/src/parse.y:1386 #13 0x430c31 in shell_getc /usr/homes/chet/src/bash/src/parse.y:2288 #14 0x433468 in read_token /usr/homes/chet/src/bash/src/parse.y:3080 #15 0x432144 in yylex /usr/homes/chet/src/bash/src/parse.y:2662 #16 0x4270b1 in yyparse /mnt/ram/bash-4.4-alpha/y.tab.c:1830 #17 0x426117 in parse_command /mnt/ram/bash-4.4-alpha/eval.c:241 #18 0x426358 in read_command /mnt/ram/bash-4.4-alpha/eval.c:285 #19 0x425921 in reader_loop /mnt/ram/bash-4.4-alpha/eval.c:148 #20 0x420bdf in main /mnt/ram/bash-4.4-alpha/shell.c:760 #21 0x7feffcaebf9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f) #22 0x41f948 (/mnt/ram/bash-4.4-alpha/bash+0x41f948) 0x60202d6f is located 1 bytes to the left of 2-byte region [0x60202d70,0x60202d72) allocated by thread T0 here: #0 0x7feffd31b787 in malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libasan.so.1+0x57787) #1 0x52f7c1 in xmalloc /mnt/ram/bash-4.4-alpha/xmalloc.c:112 #2 0x5cc9bf in remove_duplicate_matches /mnt/ram/bash-4.4-alpha/lib/readline/complete.c:1266 #3 0x5ce21b in postprocess_matches /mnt/ram/bash-4.4-alpha/lib/readline/complete.c:1485 #4 0x5d0dcb in rl_complete_internal /mnt/ram/bash-4.4-alpha/lib/readline/complete.c:2053 #5 0x5c986a in rl_complete /mnt/ram/bash-4.4-alpha/lib/readline/complete.c:431 #6 0x5b7457 in _rl_dispatch_subseq /mnt/ram/bash-4.4-alpha/lib/readline/readline.c:860 #7 0x5b7032 in _rl_dispatch /mnt/ram/bash-4.4-alpha/lib/readline/readline.c:803 #8 0x5b683d in readline_internal_char /mnt/ram/bash-4.4-alpha/lib/readline/readline.c:630 #9 0x5b68cd in readline_internal_charloop /mnt/ram/bash-4.4-alpha/lib/readline/readline.c:657 #10 0x5b68f6 in readline_internal /mnt/ram/bash-4.4-alpha/lib/readline/readline.c:671 #11 0x5b5f1e in readline /mnt/ram/bash-4.4-alpha/lib/readline/readline.c:376 #12 0x42ea53 in yy_readline_get /usr/homes/chet/src/bash/src/parse.y:1452 #13 0x42e8ff in yy_getc /usr/homes/chet/src/bash/src/parse.y:1386 #14 0x430c31 in shell_getc /usr/homes/chet/src/bash/src/parse.y:2288 #15 0x433468 in read_token /usr/homes/chet/src/bash/src/parse.y:3080 #16 0x432144 in yylex /usr/homes/chet/src/bash/src/parse.y:2662 #17 0x4270b1 in yyparse /mnt/ram/bash-4.4-alpha/y.tab.c:1830 #18 0x426117 in parse_command /mnt/ram/bash-4.4-alpha/eval.c:241 #19 0x426358 in read_command /mnt/ram/bash-4.4-alpha/eval.c:285 #20 0x425921 in reader_loop /mnt/ram/bash-4.4-alpha/eval.c:148 #21 0x420bdf in main /mnt/ram/bash-4.4-alpha/shell.c:760 #22 0x7feffcaebf9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f) SUMMARY: AddressSanitizer: heap-buffer-overflow /mnt/ram/bash-4.4-alpha/lib/readline/complete.c:738 printable_part Shadow bytes around the buggy address: 0x0c047fff8550: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8560: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8570: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff8590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fff85a0: fa fa fa fa fa fa fa fa fa fa fa fa fa[fa
Re: Another out of bounds heap read in bash completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/10/15 2:38 PM, Hanno Böck wrote: > Hi Chet, > > On Fri, 10 Jul 2015 14:23:25 -0400 > Chet Ramey wrote: > >>> To reproduce: >>> a) compile bash with CFLAGS="-fsanitize=address -g" >>> b) type in a=/ a >>> c) go back with the cursor behind the backslash and press tab >> >> Thanks for the report. I've attached a patch that should address the >> problem. It's not in bash-4.4-alpha. > > Can confirm the patch fixes the issue. > > However in 4.4 alpha I still get an asan error. However the stack trace > is different. Using the same reproducer? I said that patch was not in bash-4.4-alpha. If there's a different reproducer for the stack trace you're seeing, please send it along. Thanks. Chet - -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlWgEbgACgkQu1hp8GTqdKu0UgCgi6xharQYSrbx/1aRvH38avIR tnkAmwQqfwHkwVd1TbCX0CnxhtT+24+o =9C0A -END PGP SIGNATURE-
Re: Another out of bounds heap read in bash completion
On Fri, 10 Jul 2015 14:41:04 -0400 Chet Ramey wrote: > On 7/10/15 2:38 PM, Hanno Böck wrote: > > On Fri, 10 Jul 2015 14:23:25 -0400 > > Chet Ramey wrote: > > > >>> To reproduce: > >>> a) compile bash with CFLAGS="-fsanitize=address -g" > >>> b) type in a=/ a > >>> c) go back with the cursor behind the backslash and press tab > >> > >> Thanks for the report. I've attached a patch that should address > >> the problem. It's not in bash-4.4-alpha. > > > > Can confirm the patch fixes the issue. > > > > However in 4.4 alpha I still get an asan error. However the stack > > trace is different. > > Using the same reproducer? I said that patch was not in > bash-4.4-alpha. A sorry, misunderstanding. I thought you meant "the bug" is not in 4.4 alpha ;-) > If there's a different reproducer for the stack trace you're seeing, > please send it along. Thanks. No, exactly same reproducer, just a different stack trace. And if relevant: Even if I patch 4.4 alpha with your patch I get the asan error. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpBmixnCagcj.pgp Description: OpenPGP digital signature
Re: Another out of bounds heap read in bash completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/10/15 2:38 PM, Hanno Böck wrote: > Hi Chet, > > On Fri, 10 Jul 2015 14:23:25 -0400 > Chet Ramey wrote: > >>> To reproduce: >>> a) compile bash with CFLAGS="-fsanitize=address -g" >>> b) type in a=/ a >>> c) go back with the cursor behind the backslash and press tab >> >> Thanks for the report. I've attached a patch that should address the >> problem. It's not in bash-4.4-alpha. > > Can confirm the patch fixes the issue. > > However in 4.4 alpha I still get an asan error. However the stack trace > is different. > > Here's the asan message on 4.4 alpha: > ==5999==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000 002d6f at pc 0x5ca2b8 bp 0x7fffc9d75240 sp 0x7fffc9d75230 > READ of size 1 at 0x60202d6f thread T0 > #0 0x5ca2b7 in printable_part /mnt/ram/bash-4.4-alpha/lib/readline/co mplete.c:738 I can't reproduce this on fedora 22. If you can, please run this from inside gdb and tell me what the values of `pathname', `x', `temp' are when it crashes. Thanks. Chet - -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlWgHiMACgkQu1hp8GTqdKsgyQCeNHnussgxpn/UZvrqNane7NrP XeQAn0kRjJJlpjPkUIB6IoWTvFPmgEwc =BDRh -END PGP SIGNATURE-
Re: Another out of bounds heap read in bash completion
On Fri, 10 Jul 2015 15:34:02 -0400 Chet Ramey wrote: > > Here's the asan message on 4.4 alpha: > > ==5999==ERROR: AddressSanitizer: heap-buffer-overflow on address > > 0x602000 > 002d6f at pc 0x5ca2b8 bp 0x7fffc9d75240 sp 0x7fffc9d75230 > > READ of size 1 at 0x60202d6f thread T0 > > #0 0x5ca2b7 in > > printable_part /mnt/ram/bash-4.4-alpha/lib/readline/co > mplete.c:738 > > I can't reproduce this on fedora 22. If you can, please run this from > inside gdb and tell me what the values of `pathname', `x', `temp' are > when it crashes. Thanks. I was unable to get this working in gdb, but I added some printf: pathname 11728 x 11727 temp 11728 -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgpK9QbB0nAxO.pgp Description: OpenPGP digital signature
Re: Another out of bounds heap read in bash completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/10/15 3:42 PM, Hanno Böck wrote: > On Fri, 10 Jul 2015 15:34:02 -0400 > Chet Ramey wrote: > >>> Here's the asan message on 4.4 alpha: >>> ==5999==ERROR: AddressSanitizer: heap-buffer-overflow on address >>> 0x602000 >> 002d6f at pc 0x5ca2b8 bp 0x7fffc9d75240 sp 0x7fffc9d75230 >>> READ of size 1 at 0x60202d6f thread T0 >>> #0 0x5ca2b7 in >>> printable_part /mnt/ram/bash-4.4-alpha/lib/readline/co >> mplete.c:738 >> >> I can't reproduce this on fedora 22. If you can, please run this from >> inside gdb and tell me what the values of `pathname', `x', `temp' are >> when it crashes. Thanks. > > I was unable to get this working in gdb, but I added some printf: > pathname 11728 > x 11727 > temp 11728 That helps, but they are strings, so can you print the string values? I'm interested in reproducing this instead of just guessing and not being able to fix it at an appropriately high level. Thanks. Chet - -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlWgJFEACgkQu1hp8GTqdKsVXQCfXhbs79HZDjelAMAZyVzBn5JC 3T8AmweT5V/YrQt6rrK5IGFWiDXF+oHZ =uMh5 -END PGP SIGNATURE-
Re: Another out of bounds heap read in bash completion
On Fri, 10 Jul 2015 16:00:25 -0400 Chet Ramey wrote: > That helps, but they are strings, so can you print the string > values? I'm interested in reproducing this instead of just guessing > and not being able to fix it at an appropriately high level. Thanks. pathname / x */ temp / -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgprSEIQ1hgNo.pgp Description: OpenPGP digital signature
Re: segfault after disabling a loadable builtin
On 7/7/15 5:49 PM, Piotr Grzybowski wrote:
> hi,
>
> maybe I am mistaken, but I think that keeping track of the
> variables/functions bound/unbound by the loadable bultins leads to a
> complete hell of unmanageable code.
> It should be noted, that the builtins should clean by themselves,
> e.g., in this case mypid.c should contain something like:
>
> int __attribute__((destructor)) enable_mypid_builtin_destructor(void) {
> unbind_variable("MYPID");
> }
>
> which removes the calls to noexistent code after the builtin code has
> been removed via dlclose, and cleans the segfault.
This is the right approach, but a disable hook (destructor) needs to be
part of the interface somehow, which has potentially wide-ranging
consequences. I will have to think about how to do it.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Another out of bounds heap read in bash completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/10/15 4:15 PM, Hanno Böck wrote: > On Fri, 10 Jul 2015 16:00:25 -0400 > Chet Ramey wrote: > >> That helps, but they are strings, so can you print the string >> values? I'm interested in reproducing this instead of just guessing >> and not being able to fix it at an appropriately high level. Thanks. > > pathname / > x */ > temp / Perfect, thanks. Try the attached patch. Chet - -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlWgLBUACgkQu1hp8GTqdKv/0wCbBMH1bbwy9lP72OuGGX8vaUvq PSYAniQu+16YP6AZv5sDuhU9fbfQISAI =gqWW -END PGP SIGNATURE- *** ../bash-4.4-alpha/lib/readline/complete.c 2015-01-14 15:27:35.0 -0500 --- lib/readline/complete.c 2015-07-10 16:30:45.0 -0400 *** *** 727,730 --- 727,732 if (temp == 0 || *temp == '\0') return (pathname); + else if (temp[1] == 0 && temp == pathname) + return (pathname); /* If the basename is NULL, we might have a pathname like '/usr/src/'. Look for a previous slash and, if one is found, return the portion
Re: Another out of bounds heap read in bash completion
On Fri, 10 Jul 2015 16:33:34 -0400 Chet Ramey wrote: > Perfect, thanks. Try the attached patch. Yep, fixes the bug. Thanks! -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgp7AW88NhmiX.pgp Description: OpenPGP digital signature
Re: missing sanity checks for malloc() in bash-4.3.3x in directory 'support', file 'man2html.c'
On 7/8/15 4:57 PM, Bill Parker wrote: > Hello All, > In reviewing code in directory 'support, file 'man2html.c', I found > numerous instances of calls to malloc() being made, without a check for > a return value of NULL, indicating failure. The patch file below adds > the checks after calls to malloc(): Thanks, I'll take a look. This code has existed in essentially this form for about 15 years without a problem -- I'm the only one who really needs to ever run it -- so it might be simpler to just replace `malloc' with `xmalloc' and copy xmalloc from the rest of bash. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: address XXX comment at lines 987-990 in bashfile.c
On Thu, Jul 09, 2015 at 01:53:52PM -0700, Bill Parker wrote: > Hello All, > >In reviewing the code at line 990 in bashfile.c, while the > issue of rl_line_buffer[0] = '\0', would it not be better to > use memset(rl_line_buffer, '\0', sizeof(rl_line_buffer)) to > clobber the entire line more effectively? The patch file > below addresses this issue: [...] I don't think the intention of that line is to clear the whole buffer. If that buffer is to hold a C string, then the current code is sufficient to make that a 'null' string. -- Eduardo Bustamante https://dualbus.me/
