[Bug gdb/24611] New: dynamic-stack-buffer-overflow in linespec_lexer_lex_string

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24611] New: dynamic-stack-buffer-overflow in linespec_lexer_lex_string

alahay01 at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24611

            Bug ID: 24611
           Summary: dynamic-stack-buffer-overflow in
                    linespec_lexer_lex_string
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Compiling gdb with -lasan and -fsanitizer=address and running tests with export
ASAN_OPTIONS="detect_leaks=0:alloc_dealloc_mismatch=0", I run into:
...
PASS: gdb.linespec/cpls-abi-tag.exp: test_abi_tag: completion: at tag: cmd
complete "b test_abi_tag_function[abi"
ERROR: GDB process no longer exists
UNRESOLVED: gdb.linespec/cpls-abi-tag.exp: test_abi_tag: completion: at tag:
tab complete "b test_abi_tag_function[abi:"
...

In more detail:
...
==3637==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address
0x7fff5952bbdd at pc 0x000000fe5c57 bp 0x7fff5952af30 sp 0x7fff5952af28
READ of size 1 at 0x7fff5952bbdd thread T0
    #0 0xfe5c56 in linespec_lexer_lex_string
/data/gdb_versions/devel/src/gdb/linespec.c:727
    #1 0xfe7473 in linespec_lexer_lex_one
/data/gdb_versions/devel/src/gdb/linespec.c:946
    #2 0xfe799d in linespec_lexer_consume_token
/data/gdb_versions/devel/src/gdb/linespec.c:982
    #3 0xff446d in parse_linespec
/data/gdb_versions/devel/src/gdb/linespec.c:2564
    #4 0xff78be in linespec_complete(completion_tracker&, char const*,
symbol_name_match_type) /data/gdb_versions/devel/src/gdb/linespec.c:2961
    #5 0xb9299c in complete_address_and_linespec_locations
/data/gdb_versions/devel/src/gdb/completer.c:573
    #6 0xb93e90 in location_completer(cmd_list_element*, completion_tracker&,
char const*, char const*) /data/gdb_versions/devel/src/gdb/completer.c:919
    #7 0xb940c5 in location_completer_handle_brkchars
/data/gdb_versions/devel/src/gdb/completer.c:956
    #8 0xb957ec in complete_line_internal_normal_command
/data/gdb_versions/devel/src/gdb/completer.c:1208
    #9 0xb96507 in complete_line_internal_1
/data/gdb_versions/devel/src/gdb/completer.c:1430
    #10 0xb965c2 in complete_line_internal
/data/gdb_versions/devel/src/gdb/completer.c:1449
    #11 0xb98630 in gdb_completion_word_break_characters_throw
/data/gdb_versions/devel/src/gdb/completer.c:1862
    #12 0xb98838 in gdb_completion_word_break_characters()
/data/gdb_versions/devel/src/gdb/completer.c:1897
    #13 0x16c6362 in _rl_find_completion_word
/data/gdb_versions/devel/src/readline/complete.c:943
    #14 0x16ca8d0 in rl_complete_internal
/data/gdb_versions/devel/src/readline/complete.c:1843
    #15 0x16c460c in rl_complete
/data/gdb_versions/devel/src/readline/complete.c:408
    #16 0x16b3368 in _rl_dispatch_subseq
/data/gdb_versions/devel/src/readline/readline.c:774
    #17 0x16b3092 in _rl_dispatch
/data/gdb_versions/devel/src/readline/readline.c:724
    #18 0x16b2939 in readline_internal_char
/data/gdb_versions/devel/src/readline/readline.c:552
    #19 0x16f1fb0 in rl_callback_read_char
/data/gdb_versions/devel/src/readline/callback.c:201
    #20 0xddc5a1 in gdb_rl_callback_read_char_wrapper_noexcept
/data/gdb_versions/devel/src/gdb/event-top.c:175
    #21 0xddc773 in gdb_rl_callback_read_char_wrapper
/data/gdb_versions/devel/src/gdb/event-top.c:192
    #22 0xddd9f5 in stdin_event_handler(int, void*)
/data/gdb_versions/devel/src/gdb/event-top.c:514
    #23 0xdd7d8f in handle_file_event
/data/gdb_versions/devel/src/gdb/event-loop.c:731
    #24 0xdd8607 in gdb_wait_for_event
/data/gdb_versions/devel/src/gdb/event-loop.c:857
    #25 0xdd629c in gdb_do_one_event()
/data/gdb_versions/devel/src/gdb/event-loop.c:321
    #26 0xdd6344 in start_event_loop()
/data/gdb_versions/devel/src/gdb/event-loop.c:370
    #27 0x10a7715 in captured_command_loop
/data/gdb_versions/devel/src/gdb/main.c:331
    #28 0x10aa548 in captured_main /data/gdb_versions/devel/src/gdb/main.c:1173
    #29 0x10aa5d8 in gdb_main(captured_main_args*)
/data/gdb_versions/devel/src/gdb/main.c:1188
    #30 0x87bd35 in main /data/gdb_versions/devel/src/gdb/gdb.c:32
    #31 0x7fb0364c6f89 in __libc_start_main (/lib64/libc.so.6+0x20f89)
    #32 0x87bb49 in _start (/data/gdb_versions/devel/build/gdb/gdb+0x87bb49)

Address 0x7fff5952bbdd is located in stack of thread T0 at offset 557 in frame
    #0 0xb93702 in location_completer(cmd_list_element*, completion_tracker&,
char const*, char const*) /data/gdb_versions/devel/src/gdb/completer.c:831

  This frame has 4 object(s):
    [32, 40) 'copy'
    [96, 104) 'location'
    [160, 168) 'text'
    [224, 256) 'completion_info' <== Memory access at offset 557 overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow
/data/gdb_versions/devel/src/gdb/linespec.c:727 in linespec_lexer_lex_string
Shadow bytes around the buggy address:
  0x10006b29d720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006b29d730: 00 00 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2
  0x10006b29d740: f2 f2 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2
  0x10006b29d750: f2 f2 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00
  0x10006b29d760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10006b29d770: 00 00 00 00 ca ca ca ca 00 00 00[05]cb cb cb cb
  0x10006b29d780: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x10006b29d790: 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3
  0x10006b29d7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006b29d7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006b29d7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==3637==ABORTING
...

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24611] dynamic-stack-buffer-overflow in linespec_lexer_lex_string

alahay01 at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24611

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24611] dynamic-stack-buffer-overflow in linespec_lexer_lex_string

alahay01 at gcc dot gnu.org
In reply to this post by alahay01 at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24611

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Using this patch:
...
diff --git a/gdb/linespec.c b/gdb/linespec.c
index f418e03b77..acc0e2ca81 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -724,6 +724,8 @@ linespec_lexer_lex_string (linespec_parser *parser)

       while (1)
        {
+         fprintf (stderr, "PARSER_STREAM (parser): %p\n", (PARSER_STREAM
(parser)));
+         fprintf (stderr, "PARSER_STREAM (parser): %s\n", (PARSER_STREAM
(parser)));
          if (isspace (*PARSER_STREAM (parser)))
            {
              p = skip_spaces (PARSER_STREAM (parser));
...
I get:
...
(gdb) b test_abi_tag_function[abi"
b test_abi_tag_function[abi:PARSER_STREAM (parser): 0x7ffd84a829e2
PARSER_STREAM (parser): test_abi_tag_function[abi:
PARSER_STREAM (parser): 0x7ffd84a829e3
PARSER_STREAM (parser): est_abi_tag_function[abi:
PARSER_STREAM (parser): 0x7ffd84a829e4
PARSER_STREAM (parser): st_abi_tag_function[abi:
PARSER_STREAM (parser): 0x7ffd84a829e5
PARSER_STREAM (parser): t_abi_tag_function[abi:
PARSER_STREAM (parser): 0x7ffd84a829e6
PARSER_STREAM (parser): _abi_tag_function[abi:
PARSER_STREAM (parser): 0x7ffd84a829e7
PARSER_STREAM (parser): abi_tag_function[abi:
PARSER_STREAM (parser): 0x7ffd84a829e8
PARSER_STREAM (parser): bi_tag_function[abi:
PARSER_STREAM (parser): 0x7ffd84a829e9
PARSER_STREAM (parser): i_tag_function[abi:
PARSER_STREAM (parser): 0x7ffd84a829ea
PARSER_STREAM (parser): _tag_function[abi:
PARSER_STREAM (parser): 0x7ffd84a829eb
PARSER_STREAM (parser): tag_function[abi:
PARSER_STREAM (parser): 0x7ffd84a829ec
PARSER_STREAM (parser): ag_function[abi:
PARSER_STREAM (parser): 0x7ffd84a829ed
PARSER_STREAM (parser): g_function[abi:
PARSER_STREAM (parser): 0x7ffd84a829ee
PARSER_STREAM (parser): _function[abi:
PARSER_STREAM (parser): 0x7ffd84a829ef
PARSER_STREAM (parser): function[abi:
PARSER_STREAM (parser): 0x7ffd84a829f0
PARSER_STREAM (parser): unction[abi:
PARSER_STREAM (parser): 0x7ffd84a829f1
PARSER_STREAM (parser): nction[abi:
PARSER_STREAM (parser): 0x7ffd84a829f2
PARSER_STREAM (parser): ction[abi:
PARSER_STREAM (parser): 0x7ffd84a829f3
PARSER_STREAM (parser): tion[abi:
PARSER_STREAM (parser): 0x7ffd84a829f4
PARSER_STREAM (parser): ion[abi:
PARSER_STREAM (parser): 0x7ffd84a829f5
PARSER_STREAM (parser): on[abi:
PARSER_STREAM (parser): 0x7ffd84a829f6
PARSER_STREAM (parser): n[abi:
PARSER_STREAM (parser): 0x7ffd84a829f7
PARSER_STREAM (parser): [abi:
PARSER_STREAM (parser): 0x7ffd84a829f8
PARSER_STREAM (parser): abi:
PARSER_STREAM (parser): 0x7ffd84a829f9
PARSER_STREAM (parser): bi:
PARSER_STREAM (parser): 0x7ffd84a829fa
PARSER_STREAM (parser): i:
PARSER_STREAM (parser): 0x7ffd84a829fb
PARSER_STREAM (parser): :
PARSER_STREAM (parser): 0x7ffd84a829fd
=================================================================
==13189==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address
0x7ffd84a829fd at pc 0x7f0defff9d84 bp 0x7ffd84a81c30 sp 0x7ffd84a813e0
READ of size 2 at 0x7ffd84a829fd thread T0
    #0 0x7f0defff9d83  (/usr/lib64/libasan.so.5+0x4ed83)
    #1 0x7f0defffaa22 in __interceptor_vfprintf
(/usr/lib64/libasan.so.5+0x4fa22)
    #2 0x7f0defffaae6 in fprintf (/usr/lib64/libasan.so.5+0x4fae6)
    #3 0xfe5d0b in linespec_lexer_lex_string
/data/gdb_versions/devel/src/gdb/linespec.c:728
...
we can see what goes wrong.

At 0x7ffd84a829fb we have ":\0". When processing the colon, we skip two chars,
ending up at 0x7ffd84a829fd, _after_ the '\0'. Dereferencing that pointer
triggers the dynamic-stack-buffer-overflow.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24611] dynamic-stack-buffer-overflow in linespec_lexer_lex_string

alahay01 at gcc dot gnu.org
In reply to this post by alahay01 at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24611

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Translated into an assert:
...
diff --git a/gdb/linespec.c b/gdb/linespec.c
index f418e03b77..de57d17bbd 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -861,6 +861,7 @@ linespec_lexer_lex_string (linespec_parser *parser)
            }

          /* Advance the stream.  */
+         gdb_assert (*(PARSER_STREAM (parser)) != '\0');
          ++(PARSER_STREAM (parser));
        }
     }
...

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24611] dynamic-stack-buffer-overflow in linespec_lexer_lex_string

alahay01 at gcc dot gnu.org
In reply to this post by alahay01 at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24611

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
Tentative patch:
...
diff --git a/gdb/linespec.c b/gdb/linespec.c
index f418e03b77..8720eedfb0 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -760,7 +760,10 @@ linespec_lexer_lex_string (linespec_parser *parser)
              /* Do not tokenize ABI tags such as "[abi:cxx11]".  */
              else if (PARSER_STREAM (parser) - start > 4
                       && startswith (PARSER_STREAM (parser) - 4, "[abi"))
-               ++(PARSER_STREAM (parser));
+               {
+                 ++(PARSER_STREAM (parser));
+                 continue;
+               }

              /* Do not tokenify if the input length so far is one
                 (i.e, a single-letter drive name) and the next character
...

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24611] dynamic-stack-buffer-overflow in linespec_lexer_lex_string

alahay01 at gcc dot gnu.org
In reply to this post by alahay01 at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24611

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
patch submitted: https://sourceware.org/ml/gdb-patches/2019-05/msg00569.html

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24611] dynamic-stack-buffer-overflow in linespec_lexer_lex_string

alahay01 at gcc dot gnu.org
In reply to this post by alahay01 at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24611

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <[hidden email]>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f19e22e9226444ee566b5b5633c0a48a4f981eda

commit f19e22e9226444ee566b5b5633c0a48a4f981eda
Author: Tom de Vries <[hidden email]>
Date:   Mon Jun 10 20:17:14 2019 +0200

    [gdb] Fix dynamic-stack-buffer-overflow in linespec_lexer_lex_string

    When compiling gdb with '-lasan -fsanitizer=address' and running tests with
    'export ASAN_OPTIONS="detect_leaks=0:alloc_dealloc_mismatch=0"', I run
into:
    ...
    ERROR: GDB process no longer exists
    UNRESOLVED: gdb.linespec/cpls-abi-tag.exp: \
      test_abi_tag: completion: at tag: tab complete "b
test_abi_tag_function[abi:"
    ...

    In more detail:
    ...
    ==3637==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address \
      0x7fff5952bbdd at pc 0x000000fe5c57 bp 0x7fff5952af30 sp 0x7fff5952af28
    READ of size 1 at 0x7fff5952bbdd thread T0
        #0 0xfe5c56 in linespec_lexer_lex_string src/gdb/linespec.c:727
        #1 0xfe7473 in linespec_lexer_lex_one src/gdb/linespec.c:946
        #2 0xfe799d in linespec_lexer_consume_token src/gdb/linespec.c:982
        #3 0xff446d in parse_linespec src/gdb/linespec.c:2564
        #4 0xff78be in linespec_complete(completion_tracker&, char const*, \
                       symbol_name_match_type) src/gdb/linespec.c:2961
        #5 0xb9299c in complete_address_and_linespec_locations \
                       src/gdb/completer.c:573
        #6 0xb93e90 in location_completer(cmd_list_element*,
completion_tracker&, \
                       char const*, char const*) src/gdb/completer.c:919
        #7 0xb940c5 in location_completer_handle_brkchars
src/gdb/completer.c:956
        #8 0xb957ec in complete_line_internal_normal_command \
                       src/gdb/completer.c:1208
        #9 0xb96507 in complete_line_internal_1 src/gdb/completer.c:1430
        #10 0xb965c2 in complete_line_internal src/gdb/completer.c:1449
        #11 0xb98630 in gdb_completion_word_break_characters_throw \
                        src/gdb/completer.c:1862
        #12 0xb98838 in gdb_completion_word_break_characters() \
                        src/gdb/completer.c:1897
        #13 0x16c6362 in _rl_find_completion_word src/readline/complete.c:943
        #14 0x16ca8d0 in rl_complete_internal src/readline/complete.c:1843
        #15 0x16c460c in rl_complete src/readline/complete.c:408
        #16 0x16b3368 in _rl_dispatch_subseq src/readline/readline.c:774
        #17 0x16b3092 in _rl_dispatch src/readline/readline.c:724
        #18 0x16b2939 in readline_internal_char src/readline/readline.c:552
        #19 0x16f1fb0 in rl_callback_read_char src/readline/callback.c:201
        #20 0xddc5a1 in gdb_rl_callback_read_char_wrapper_noexcept \
                        src/gdb/event-top.c:175
        #21 0xddc773 in gdb_rl_callback_read_char_wrapper
src/gdb/event-top.c:192
        #22 0xddd9f5 in stdin_event_handler(int, void*) src/gdb/event-top.c:514
        #23 0xdd7d8f in handle_file_event src/gdb/event-loop.c:731
        #24 0xdd8607 in gdb_wait_for_event src/gdb/event-loop.c:857
        #25 0xdd629c in gdb_do_one_event() src/gdb/event-loop.c:321
        #26 0xdd6344 in start_event_loop() src/gdb/event-loop.c:370
        #27 0x10a7715 in captured_command_loop src/gdb/main.c:331
        #28 0x10aa548 in captured_main src/gdb/main.c:1173
        #29 0x10aa5d8 in gdb_main(captured_main_args*) src/gdb/main.c:1188
        #30 0x87bd35 in main src/gdb/gdb.c:32
        #31 0x7fb0364c6f89 in __libc_start_main (/lib64/libc.so.6+0x20f89)
        #32 0x87bb49 in _start (build/gdb/gdb+0x87bb49)

    Address 0x7fff5952bbdd is located in stack of thread T0 at offset 557 in
frame
        #0 0xb93702 in location_completer(cmd_list_element*,
completion_tracker&, \
                       char const*, char const*) src/gdb/completer.c:831

      This frame has 4 object(s):
        [32, 40) 'copy'
        [96, 104) 'location'
        [160, 168) 'text'
        [224, 256) 'completion_info' <== Memory access at offset 557 overflows
\
                                        this variable
    HINT: this may be a false positive if your program uses some custom stack \
          unwind mechanism or swapcontext
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow \
             src/gdb/linespec.c:727 in linespec_lexer_lex_string
    Shadow bytes around the buggy address:
      0x10006b29d720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006b29d730: 00 00 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2
      0x10006b29d740: f2 f2 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2
      0x10006b29d750: f2 f2 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00
      0x10006b29d760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x10006b29d770: 00 00 00 00 ca ca ca ca 00 00 00[05]cb cb cb cb
      0x10006b29d780: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
      0x10006b29d790: 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3
      0x10006b29d7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006b29d7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006b29d7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
    ==3637==ABORTING
    ...

    The problem happens in linespec_lexer_lex_string when lexing
    "b test_abi_tag_function[abi:\0" (using a notation where we make the
implicit
    terminating \0 explicit).

    We arrrive here with (PARSER_STREAM (parser)) == ":\0":
    ...
                 /* Do not tokenize ABI tags such as "[abi:cxx11]".  */
                 else if (PARSER_STREAM (parser) - start > 4
                          && startswith (PARSER_STREAM (parser) - 4, "[abi"))
                   ++(PARSER_STREAM (parser));
    ...
    and consume ':', after which we end up here and consume '\0':
    ...
             /* Advance the stream.  */
             ++(PARSER_STREAM (parser));
    ...
    after which (PARSER_STREAM (parser)) points past the end of the string.

    Fix this by removing the first "++(PARSER_STREAM (parser))", and add an
assert
    to the second one to detect moving past the end-of-string.

    Build and tested on x86_64-linux.

    gdb/ChangeLog:

    2019-06-10  Tom de Vries  <[hidden email]>

        PR gdb/24611
        * linespec.c (linespec_lexer_lex_string): Remove incorrect
        "++(PARSER_STREAM (parser))" for "[abi"-prefixed colon.  Add assert.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/24611] dynamic-stack-buffer-overflow in linespec_lexer_lex_string

alahay01 at gcc dot gnu.org
In reply to this post by alahay01 at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24611

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch committed, marking resolved-fixed.

--
You are receiving this mail because:
You are on the CC list for the bug.