[Bug-readline] heap-buffer-overflow in update_line

  On 16-05-19 22:50, Chet Ramey wrote:
> On 5/8/19 4:10 PM, Tom de Vries wrote:
>> Hi,
>>
>> when:
>> - building trunk gdb (using the readline sources in the binutils-gdb.git
>>   repo) on openSUSE 15.0 x86_64-linux with -fsanitize=address, and:
>> - running gdb tests with "export ASAN_OPTIONS=detect_leaks=0",
>> I run into a heap-buffer-overflow failure for
>> gdb.base/utf8-identifiers.exp, reported as PR gdb/24514 -
>> "heap-buffer-overflow in update_line for utf8-identifiers.exp"  at
>> https://sourceware.org/bugzilla/show_bug.cgi?id=24514 .
> 
> 			[...]
> 
>> which triggers without needing the address sanitizer, like this:
>> ...
>> $ TERM=dumb gdb -q -ex "set width 0"
>> gdb: /home/vries/readline/src/display.c:1393: rl_redisplay: Assertion
>> `last_lmargin + (_rl_screenwidth + visible_wrap_offset) <= line_size'
>> failed.
>> Aborted (core dumped)
> 
> This looks like the same problem as described in
> 
> http://lists.gnu.org/archive/html/bug-readline/2019-03/msg00001.html
> 
> In this case, gdb sets the screen width to 32766, which is obviously
> bonkers on a dumb terminal. Gdb should pass -1 to rl_set_screen_size
> so readline doesn't override the number of columns on the physical
> terminal.
> 

I've tried this:
...
but ran into this test failure in gdb.ada/pp-rec-component.exp:
...
(gdb) source
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.ada/pp^M<sions/devel/build/gdb/testsuite/outputs/gdb.ada/pp-

^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hrec-component/pp-rec-com
^M<tsuite/outputs/gdb.ada/pp-rec-component/pp-rec-comp
      ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Honent.py^M
(gdb) FAIL: gdb.ada/pp-rec-component.exp: source pp-rec-component.py
...
which is readline doing it's horizontal scrolling mode, which AFAIU is
triggered by this condition in rl_redisplay failing:
...
  if (_rl_horizontal_scroll_mode == 0 && _rl_term_up && *_rl_term_up)
...
not because _rl_horizontal_scroll_mode is 1, but because _rl_term_up is
NULL (because of TERM=dumb).

Note btw that ^H is used here by readline despite the fact that
TERM=dumb does not support backspace. I'm not sure if this is a bug, or
intentional behaviour.

Either way, I'm open for suggestions that make gdb call
rl_set_screen_size with legal parameters, and disable features like
horizontal scrolling to get unformatted output for the testsuite run.

Thanks,
- Tom
  

On 5/17/19 10:59 AM, Tom de Vries wrote:

> 
> I've tried this:
> ...
> diff --git a/gdb/utils.c b/gdb/utils.c
> index 9686927473..2bfa22055e 100644
> --- a/gdb/utils.c
> +++ b/gdb/utils.c
> @@ -1371,7 +1371,7 @@ set_screen_size (void)
> 
>    if (cols <= 0 || cols > sqrt_int_max)
>      {
> -      cols = sqrt_int_max;
> +      cols = -1;
>        chars_per_line = UINT_MAX;
>      }

It's not apparent from this patch whether or not gdb uses `cols' for
anything besides passing to readline.

> ...
> but ran into this test failure in gdb.ada/pp-rec-component.exp:
> ...
> (gdb) source
> /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.ada/pp^M<sions/devel/build/gdb/testsuite/outputs/gdb.ada/pp-
> 
> ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hrec-component/pp-rec-com
> ^M<tsuite/outputs/gdb.ada/pp-rec-component/pp-rec-comp
>       ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Honent.py^M
> (gdb) FAIL: gdb.ada/pp-rec-component.exp: source pp-rec-component.py
> ...
> which is readline doing it's horizontal scrolling mode, which AFAIU is
> triggered by this condition in rl_redisplay failing:
> ...
>   if (_rl_horizontal_scroll_mode == 0 && _rl_term_up && *_rl_term_up)
> ...
> not because _rl_horizontal_scroll_mode is 1, but because _rl_term_up is
> NULL (because of TERM=dumb).

Correct. If the terminal type is unknown or tgetent returns a set of
capabilities that doesn't include "up", you're going to get horizontal
scrolling.

> 
> Note btw that ^H is used here by readline despite the fact that
> TERM=dumb does not support backspace. I'm not sure if this is a bug, or
> intentional behaviour.

Readline uses what tgetent returns for "le" or defaults to "\b" if tgetent
fails. Most dumb terminals support ^H to move the cursor left one position.

> 
> Either way, I'm open for suggestions that make gdb call
> rl_set_screen_size with legal parameters, and disable features like
> horizontal scrolling to get unformatted output for the testsuite run.

You can't specify a dumb terminal and expect to have line wrapping.

Chet
  

On 5/17/19 10:59 AM, Tom de Vries wrote:

> Either way, I'm open for suggestions that make gdb call
> rl_set_screen_size with legal parameters, and disable features like
> horizontal scrolling to get unformatted output for the testsuite run.

Here's a patch that will prevent the huge values for the screen width from
causing at least one issue with line_size:

*** ../readline-8.0-patched/display.c	2018-09-30 21:37:48.000000000 -0400
--- display.c	2019-05-16 16:50:44.000000000 -0400
***************
*** 604,607 ****
--- 604,610 ----
    register int n;

+   if (line_size <= _rl_screenwidth)	/* XXX - for gdb */
+     line_size = _rl_screenwidth + 1;
+
    if (invisible_line == 0)	/* initialize it */
      {

You're still going to have to deal with some horizontal scrolling if the
input line gets long enough.
  

On 20-05-19 22:14, Chet Ramey wrote:
> On 5/17/19 10:59 AM, Tom de Vries wrote:
> 
>> Either way, I'm open for suggestions that make gdb call
>> rl_set_screen_size with legal parameters, and disable features like
>> horizontal scrolling to get unformatted output for the testsuite run.
> 
> Here's a patch that will prevent the huge values for the screen width from
> causing at least one issue with line_size:
> 
> *** ../readline-8.0-patched/display.c	2018-09-30 21:37:48.000000000 -0400
> --- display.c	2019-05-16 16:50:44.000000000 -0400
> ***************
> *** 604,607 ****
> --- 604,610 ----
>     register int n;
> 
> +   if (line_size <= _rl_screenwidth)	/* XXX - for gdb */
> +     line_size = _rl_screenwidth + 1;
> +
>     if (invisible_line == 0)	/* initialize it */
>       {
> 
> You're still going to have to deal with some horizontal scrolling if the
> input line gets long enough.
> 

Hi Chet,

thanks for the patch.

I've tried it out (together with the assert mentioned earlier) and found
that indeed it fixes the assert for the reported scenario:
...
$ TERM=dumb ./gdb -q -ex "set width 0"
(gdb)
...
but I still ran into the assert by typing the command instead of using
"-ex":
...
$ TERM=dumb ./gdb -q
(gdb) set width 0
gdb: display.c:1214: rl_redisplay: Assertion `last_lmargin +
(_rl_screenwidth + visible_wrap_offset) <= line_size' failed.
Aborted (core dumped)
...

Using this additional bit:
...
@@ -528,6 +533,8 @@ rl_redisplay ()
       init_line_structures (0);
       rl_on_new_line ();
     }
+  else if (line_size <= _rl_screenwidth)
+    init_line_structures (_rl_screenwidth + 1);

   /* Draw the line into the buffer. */
   cpos_buffer_position = -1;
...
I managed to fix the assert also in this scenario, and managed to run
the entire gdb testsuite without triggering the assert.

Is that a good code change?

Thanks,
- Tom
  

On 5/23/19 3:33 AM, Tom de Vries wrote:

> Using this additional bit:
> ...
> @@ -528,6 +533,8 @@ rl_redisplay ()
>        init_line_structures (0);
>        rl_on_new_line ();
>      }
> +  else if (line_size <= _rl_screenwidth)
> +    init_line_structures (_rl_screenwidth + 1);
> 
>    /* Draw the line into the buffer. */
>    cpos_buffer_position = -1;
> ...
> I managed to fix the assert also in this scenario, and managed to run
> the entire gdb testsuite without triggering the assert.
> 
> Is that a good code change?

It looks like it will solve that problem, and perhaps more. Thanks for the
patch.

Chet