RE: cygheap base mismatch detected

2017-06-16 Thread Jon Morris 
No problem. I don't have cygwin installed so the problem is something is 
looking for it. I've reinstalled git for windows so if the problem doesn't go 
away, I'll raise a defect with Cmder.

Thanks,

Jon

-Original Message-
From: Eduardo Bustamante [mailto:dual...@gmail.com]
Sent: 15 June 2017 19:22
To: Jon Morris 
Cc: bug-bash@gnu.org
Subject: Re: cygheap base mismatch detected

On Thu, Jun 15, 2017 at 1:19 PM, Eduardo Bustamante  wrote:
[..]
> Please report this to the Cygwin folks. This is not a bash issue.

Err, not the Cygwin folks. You seem to be using Cmder, so ask them.
Find out more about us here: www.jbarisk.com and 
follow us on Twitter @JBARisk and 
LinkedIn

The JBA Group supports the JBA Trust.

All JBA Risk Management's email messages contain confidential information and 
are intended only for the individual(s) named. If you are not the named 
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by email if you have received this email 
by mistake and delete this email from your system.


JBA Risk Management Limited is registered in England, company number 07732946, 
South Barn, Broughton Hall, Skipton, North Yorkshire, BD23 3AE, Telephone: 
+441756799919

Re: AddressSanitizer: heap-buffer-overflow in rl_delete

2017-06-16 Thread Eduardo A . Bustamante López 
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 
> 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)
> #1 0x5634e38634c3 in _rl_find_next_mbchar_internal 
> (/home/dualbus/src/gnu/bash-build/bash+0x25d4c3)
> #2 0x5634e3864375 in _rl_find_next_mbchar 
> (/home/dualbus/src/gnu/bash-build/bash+0x25e375)
> #3 0x5634e3850c0e in rl_delete 
> (/home/dualbus/src/gnu/bash-build/bash+0x24ac0e)

OK. Here's an easy way to reproduce this.

- Start on an empty rl_line_buffer
- Call `set-mark' with a numeric argument (a large number, e.g. 500, is better).
- Call `exchange-point-and-mark' so that now rl_point = 500
- Call `delete-char'
- Bash crashes

The _rl_set_mark_at_pos function already checks for `position > rl_end',
so I'm not sure how to fix this.

-- 
Eduardo Bustamante
https://dualbus.me/

Re: AddressSanitizer: global-buffer-overflow in rl_filename_completion_function

2017-06-16 Thread Eduardo A . Bustamante López 
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 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/src/gnu/bash-build/bash+0x17a6c9)

Easy fix. `p' is a signed char pointer, therefore when `*p = 255', it tries to
dereference `sh_syntaxtab[-1]'.

dualbus@debian:~/src/gnu/bash$ git difftool -y -x 'diff -c' -- bashline.c
*** /tmp/mVc4sH_bashline.c  2017-06-16 09:52:56.471508904 -0500
--- bashline.c  2017-06-16 09:48:55.706503276 -0500
***
*** 3886,3892 
*r++ = *p;
  /* Backslashes are preserved within double quotes unless the
 character is one that is defined to be escaped */
! else if (quoted == '"' && ((sh_syntaxtab[p[1]] & CBSDQUOTE) == 0))
*r++ = *p;
  
  *r++ = *++p;
--- 3886,3892 
*r++ = *p;
  /* Backslashes are preserved within double quotes unless the
 character is one that is defined to be escaped */
! else if (quoted == '"' && ((sh_syntaxtab[(unsigned char)p[1]] & 
CBSDQUOTE) == 0))
*r++ = *p;
  
  *r++ = *++p;





Maybe it's a good idea to change these too. In locale.c there shouldn't be a
problem, because the loop is constrained to `x < sh_syntabsiz', but perhaps
just to silence compiler warnings :-)?

dualbus@debian:~/src/gnu/bash$ git difftool -y -x 'diff -c' -- locale.c parse.y 
*** /tmp/OyLWya_locale.c2017-06-16 09:55:15.854368199 -0500
--- locale.c2017-06-16 09:50:52.816950476 -0500
***
*** 552,565 
for (x = 0; x < sh_syntabsiz; x++)
  {
if (isblank ((unsigned char)x))
!   sh_syntaxtab[x] |= CSHBRK|CBLANK;
else if (member (x, shell_break_chars))
{
! sh_syntaxtab[x] |= CSHBRK;
! sh_syntaxtab[x] &= ~CBLANK;
}
else
!   sh_syntaxtab[x] &= ~(CSHBRK|CBLANK);
  }
  }
  
--- 552,565 
for (x = 0; x < sh_syntabsiz; x++)
  {
if (isblank ((unsigned char)x))
!   sh_syntaxtab[(unsigned char)x] |= CSHBRK|CBLANK;
else if (member (x, shell_break_chars))
{
! sh_syntaxtab[(unsigned char)x] |= CSHBRK;
! sh_syntaxtab[(unsigned char)x] &= ~CBLANK;
}
else
!   sh_syntaxtab[(unsigned char)x] &= ~(CSHBRK|CBLANK);
  }
  }
  
*** /tmp/qKFxWa_parse.y 2017-06-16 09:55:15.862368362 -0500
--- parse.y 2017-06-16 09:52:22.522808775 -0500
***
*** 4842,4848 
  
  /* If the next character is to be quoted, note it now. */
  if (cd == 0 || cd == '`' ||
! (cd == '"' && peek_char >= 0 && (sh_syntaxtab[peek_char] & 
CBSDQUOTE)))
pass_next_character++;
  
  quoted = 1;
--- 4842,4848 
  
  /* If the next character is to be quoted, note it now. */
  if (cd == 0 || cd == '`' ||
! (cd == '"' && peek_char >= 0 && (sh_syntaxtab[(unsigned 
char)peek_char] & CBSDQUOTE)))
pass_next_character++;
  
  quoted = 1;

-- 
Eduardo Bustamante
https://dualbus.me/

Re: AddressSanitizer: heap-buffer-overflow in rl_tilde_expand

2017-06-16 Thread Eduardo A . Bustamante López 
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 
> 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-build/bash+0x23ba13)

This one looks like an easy fix. When `start = 0', the loop ends up
dereferencing `rl_line_buffer[-1]'. Changing the order of the test does the 
trick.


dualbus@debian:~/src/gnu/bash$ git difftool -y -x 'diff -c' -- 
lib/readline/util.c 
*** /tmp/zFXFei_util.c  2017-06-16 09:34:03.958088209 -0500
--- lib/readline/util.c 2017-06-16 09:33:09.384638705 -0500
***
*** 193,199 
  }
else if (start >= 0 && rl_line_buffer[start] != '~')
  {
!   for (; !whitespace (rl_line_buffer[start]) && start >= 0; start--)
  ;
start++;
  }
--- 193,199 
  }
else if (start >= 0 && rl_line_buffer[start] != '~')
  {
!   for (; start >= 0 && !whitespace (rl_line_buffer[start]); start--)
  ;
start++;
  }

-- 
Eduardo Bustamante
https://dualbus.me/

Re: AddressSanitizer: heap-buffer-overflow in rl_kill_text

2017-06-16 Thread Eduardo A . Bustamante López 
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 
> 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/dualbus/src/gnu/bash-build/bash+0x23cbe6)

Easy fix. When `rl_kill_ring_length == rl_max_kills (10)', all of the entries
in the kill ring are shifted. The loop has an off-by-one error though.

I also think that using `rl_max_kills' in the loop instead of `slot' makes the
code easier to read.

dualbus@debian:~/src/gnu/bash$ git difftool -y -x 'diff -c' -- 
lib/readline/kill.c 
*** /tmp/uLCFvH_kill.c  2017-06-16 10:04:43.472930262 -0500
--- lib/readline/kill.c 2017-06-16 10:04:20.048344312 -0500
***
*** 113,119 
{
  register int i;
  xfree (rl_kill_ring[0]);
! for (i = 0; i < slot; i++)
rl_kill_ring[i] = rl_kill_ring[i + 1];
}
  else
--- 113,119 
{
  register int i;
  xfree (rl_kill_ring[0]);
! for (i = 0; i < rl_max_kills - 1; i++)
rl_kill_ring[i] = rl_kill_ring[i + 1];
}
  else

-- 
Eduardo Bustamante
https://dualbus.me/

Re: AddressSanitizer: heap-buffer-overflow in rl_delete

2017-06-16 Thread Chet Ramey 
On 6/16/17 10:27 AM, Eduardo A. Bustamante López wrote:
> 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 
>> 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)
>> #1 0x5634e38634c3 in _rl_find_next_mbchar_internal 
>> (/home/dualbus/src/gnu/bash-build/bash+0x25d4c3)
>> #2 0x5634e3864375 in _rl_find_next_mbchar 
>> (/home/dualbus/src/gnu/bash-build/bash+0x25e375)
>> #3 0x5634e3850c0e in rl_delete 
>> (/home/dualbus/src/gnu/bash-build/bash+0x24ac0e)
> 
> OK. Here's an easy way to reproduce this.
> 
> - Start on an empty rl_line_buffer
> - Call `set-mark' with a numeric argument (a large number, e.g. 500, is 
> better).
> - Call `exchange-point-and-mark' so that now rl_point = 500
> - Call `delete-char'
> - Bash crashes

I can't reproduce this using the current development version. Its failure
depends on rl_end already being wrong.  I've already fixed that particular
problem; it was a problem with the isearch code that requires the obscure
circumstances fuzzing brings to reproduce.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: AddressSanitizer: heap-buffer-overflow in rl_tilde_expand

2017-06-16 Thread Chet Ramey 
On 6/16/17 10:43 AM, Eduardo A. Bustamante López wrote:
> 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 
>> 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-build/bash+0x23ba13)
> 
> This one looks like an easy fix. When `start = 0', the loop ends up
> dereferencing `rl_line_buffer[-1]'. Changing the order of the test does the 
> trick.

This is indeed the right fix.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: AddressSanitizer: global-buffer-overflow in rl_filename_completion_function

2017-06-16 Thread Chet Ramey 
On 6/16/17 10:57 AM, Eduardo A. Bustamante López wrote:
> 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 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/src/gnu/bash-build/bash+0x17a6c9)
> 
> Easy fix. `p' is a signed char pointer, therefore when `*p = 255', it tries to
> dereference `sh_syntaxtab[-1]'.

This is right.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: AddressSanitizer: heap-buffer-overflow in rl_kill_text

2017-06-16 Thread Chet Ramey 
On 6/16/17 11:10 AM, Eduardo A. Bustamante López wrote:
> 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 
>> 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/dualbus/src/gnu/bash-build/bash+0x23cbe6)
> 
> Easy fix. When `rl_kill_ring_length == rl_max_kills (10)', all of the entries
> in the kill ring are shifted. The loop has an off-by-one error though.

This is one possible fix. There is also the asymmetry in the xrealloc
below.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

Re: Why does 'connect' take so long (sometimes) and can't be interrupted?

2017-06-16 Thread Chet Ramey 
On 6/15/17 11:36 AM, gaze...@xmission.com wrote:

>   Note, however, that it does eventually connect.  As far as I can tell, 
> it
>   does always eventually connect.
> 
>   Needless to say, when I first hit this problem, I assumed it had hung, 
> and
>   when I tried to kill it, I ran into the problems described above.

It's all system calls. If it hangs in `connect', bash has to wait until
the system call returns one way or another.  There is no provision for a
timeout with connect, and any signal (e.g., SIGALRM) that bash tries to
set for a timeout will be deferred until connect completes or fails
anyway.

> 
>   Also note: In testing this, I found that if I do hit ^C while it is 
> hung,
>   then wait long enough, eventually it does exit as shown below:
> 
> Elapsed time for this 'exec' ...  ^C^C^C^Cbash: connect: Connection 
> refused
> bash: /dev/tcp/localhost/12345: Connection refused

If that's a legit error, the problem might be with the server.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/