dualbus@debian:~$ LC_ALL=en_US.UTF-8 ~/src/gnu/bash/bash -c 'read -e;
declare -p REPLY'
Ñu
woops
declare -- REPLY="�w�u"
I typed: <ñ><\C-a><\ec>...
dualbus@debian:~/bash-fuzzing/bash-parser$ cat -v malloc-read_token_word
P[$(0^A^A000$(00
d0=(^?00^?0^?>000^?^A00)000^?00^?0)00^?000)00^A00
The parser goes into an infinite loop with the following input:
dualbus@debian:~/bash-fuzzing/bash-parser$ cat -v
output/13/crashes/id:42,sig:11,src:005617,op:havoc,rep:4
for ((0funcM-^Nion;)); do :M->M-aM-RM->M->e&
d^?^@e :;
done&M-wd\\\cr$\osM-ac\\M-ac\\^\\M-]\^\\M-]\\\cr\^\\M-]\\\c'M-^?^ZM
(tested against the latest devel, i.e. May/8 push)
dualbus@debian:~/src/gnu/bash$ git rev-parse HEAD
af2a77fbbcf6e50edbc535eb3fd267bd3f4d1a14
dualbus@debian:~/bash-fuzzing/bash-read/read-r$ cat -v read_builtin
000
I think `edit-and-execute-command' shouldn't be allowed under `read -e'.
dualbus@debian:~$ cat prompt.sh
#!/bin/bash
declare -p UID EUID
read -p '> ' -e
declare -p REPLY
dualbus@debian:~$ id -u
1000
dualbus@debian:~$ sudo ./prompt.sh
declare -ir UID="0"
declare -ir EUID="0"
>
id -u
0
> bye
declar
dualbus@debian:~/src/gnu/bash$ for fn in edit-and-execute-command
kill-line yank yank-pop; do echo $fn:; fn=$fn ./bash --noprofile
--norc -ic 'bind -q $fn; bind -u $fn; bind -q $fn'|sed 's/^/ /'; done
edit-and-execute-command:
edit-and-execute-command can be invoked via "\C-x\C-e".
edit-and-ex
This doesn't seem to be related to the other read memory corruption
issues, since it doesn't crash normal read/read -r.
dualbus@afl-bash-history-fncm:~$ md5sum malloc
0edd8a721e52362d0aeeb30bae22c4f5 malloc
dualbus@afl-bash-history-fncm:~$ base64 malloc
/TAw/wHw8DAw8DAwMDAw8PD19fUw9fX19fX1MP9//P
On 5/8/17 10:24 AM, Eduardo Bustamante wrote:
> dualbus@debian:~$ LC_ALL=en_US.UTF-8 ~/src/gnu/bash/bash -c 'read -e;
> declare -p REPLY'
> Ñu
> woops
> declare -- REPLY="�w�u"
>
> I typed: <ñ><\C-a><\ec>...
Thanks for the report. This is a genuine bug that people using the devel
brach are likely
I can't reproduce this one reliably, since it seems to depend on the
files present in the system. Please let me know what other information
you may need for this one.
dualbus@afl-bash-history-fncm:~$ md5sum
output/8/crashes/id:00,sig:11,src:001386+007877,op:splice,rep:8
415cbe0afff4b13b3134c78
On 5/8/17 2:18 PM, Eduardo Bustamante wrote:
> dualbus@debian:~/src/gnu/bash$ for fn in edit-and-execute-command
> kill-line yank yank-pop; do echo $fn:; fn=$fn ./bash --noprofile
> --norc -ic 'bind -q $fn; bind -u $fn; bind -q $fn'|sed 's/^/ /'; done
> edit-and-execute-command:
> edit-and-execu
On 5/8/17 1:31 PM, Eduardo Bustamante wrote:
> I think `edit-and-execute-command' shouldn't be allowed under `read -e'.
There's no compelling reason to disallow it. If a system administrator
wants to unbind certain readline commands (and unset INPUTRC!) to protect
against a specific use case, he
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2
-L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -D
On 5/8/17 4:29 PM, tob...@ryara.net wrote:
> Bash Version: 4.2
> Patch Level: 53
> Release Status: release
>
> Description:
> Bash 4.3 introduced "-1" for unlimited history.
>
> Starting bash 4.2 with HISTSIZE=-1 in ~/.bashrc causes a segmentation
> fault (assuming you have a
On Mon, May 8, 2017 at 3:09 PM, Chet Ramey wrote:
> There's no compelling reason to disallow it. If a system administrator
> wants to unbind certain readline commands (and unset INPUTRC!) to protect
> against a specific use case, he is free to do that.
I agree. I changed my mind after sending th
14 matches
Mail list logo