Project

General

Profile

Bug #3390

vty segfaults when two commands "foo [<0-23>]" and "foo <0-23> bar" coexist

Added by neels 5 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
07/09/2018
Due date:
% Done:

100%

Spec Reference:

Description

If a command exists as both with optional number argument and another variant with non-optional number argument, the vty causes use-after-free when

  • hitting tab (autocomplete) after the number arg
  • hitting enter after the number arg

This came to my attention when trying to add a 'show bts <0-255> neighbor ...' vty command, which forms this problem with 'show bts [<0-255>]'.
When duplicating to 'show bts' and 'show bts <0-255>', the problem does not occur.
When using a non-numeric arg, the problem does not occur.

A workaround is thus to copy the 'show bts' implementation, so that we don't need to use an optional arg.

Reproduction / backtrace follows.

History

#1 Updated by neels 5 months ago

I was able to trigger with this patch

diff --git a/src/osmo-bsc/bsc_vty.c b/src/osmo-bsc/bsc_vty.c
index f25f73106..0ddbed8c4 100644
--- a/src/osmo-bsc/bsc_vty.c
+++ b/src/osmo-bsc/bsc_vty.c
@@ -493,6 +493,16 @@ static void bts_dump_vty(struct vty *vty, struct gsm_bts *bts)
        bts_dump_vty_features(vty, bts);
 }

+DEFUN(xxx1, xxx1_cmd, "xxx [<0-5>]", "xxx" "nr")
+{
+       return CMD_SUCCESS;
+}
+
+DEFUN(xxx2, xxx2_cmd, "xxx <0-5>", "xxx" "nr")
+{
+       return CMD_SUCCESS;
+}
+
 DEFUN(show_bts, show_bts_cmd, "show bts [<0-255>]",
        SHOW_STR "Display information about a BTS\n" 
                "BTS number")
@@ -4826,6 +4836,8 @@ int bsc_vty_init(struct gsm_network *network)
        install_element(GSMNET_NODE, &cfg_net_meas_feed_scenario_cmd);

        install_element_ve(&bsc_show_net_cmd);
+       install_element_ve(&xxx1_cmd);
+       install_element_ve(&xxx2_cmd);
        install_element_ve(&show_bts_cmd);
        install_element_ve(&show_trx_cmd);
        install_element_ve(&show_ts_cmd);

then running osmo-bsc and on the telnet VTY issuing

OsmoBSC> xxx 0 <TAB>

or
OsmoBSC> xxx 0<ENTER>

The error is

==19016==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b000241a00 at pc 0x7efd94c2ebf0 bp 0x7fff3eab5490 sp 0x7fff3eab4c40
READ of size 6 at 0x60b000241a00 thread T0
    #0 0x7efd94c2ebef  (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x44bef)
    #1 0x7efd94946f4a in is_cmd_ambiguous ../../../../src/libosmocore/src/vty/command.c:1530
    #2 0x7efd94949d8a in cmd_execute_command_real ../../../../src/libosmocore/src/vty/command.c:2196
    #3 0x7efd9495c56f in vty_command ../../../../src/libosmocore/src/vty/vty.c:420
    #4 0x7efd9495c56f in vty_execute ../../../../src/libosmocore/src/vty/vty.c:684
    #5 0x7efd9495c56f in vty_read ../../../../src/libosmocore/src/vty/vty.c:1426
    #6 0x7efd94966d81 in client_data ../../../../src/libosmocore/src/vty/telnet_interface.c:135
    #7 0x7efd93c12f88 in osmo_fd_disp_fds ../../../src/libosmocore/src/select.c:217
    #8 0x7efd93c12f88 in osmo_select_main ../../../src/libosmocore/src/select.c:257
    #9 0x564396bf8916 in main ../../../../src/osmo-bsc/src/osmo-bsc/osmo_bsc_main.c:899
    #10 0x7efd9219d2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
    #11 0x564396bf9409 in _start (/n/s/dev/make/osmo-bsc/src/osmo-bsc/osmo-bsc+0x27f409)

0x60b000241a00 is located 96 bytes inside of 103-byte region [0x60b0002419a0,0x60b000241a07)
freed by thread T0 here:
    #0 0x7efd94caba10 in free (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1a10)
    #1 0x7efd946d886a in _talloc_free (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x486a)

previously allocated by thread T0 here:
    #0 0x7efd94cabd28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
    #1 0x7efd946da661 in talloc_named_const (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x6661)

SUMMARY: AddressSanitizer: heap-use-after-free (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x44bef) 
Shadow bytes around the buggy address:
  0x0c16800402f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1680040300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1680040310: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1680040320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c1680040330: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c1680040340:[fd]fa fa fa fa fa fa fa fa fa fd fd fd fd fd fd
  0x0c1680040350: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
  0x0c1680040360: fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa
  0x0c1680040370: fa fa fa fa fa fa 00 00 00 00 00 00 00 00 00 00
  0x0c1680040380: 00 00 00 00 fa fa fa fa fa fa fa fa 00 00 00 00
  0x0c1680040390: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
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
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  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
==19016==ABORTING

#2 Updated by neels 5 months ago

(above patch actually causes an ambiguous command, since if parsing succeeded the VTY wouldn't know whether to run the 'xxx 0' or 'xxx [0]' implementation, but that's not the point here. If more args follow after the number arg to form an unambiguous command, the same problem occurs)

#3 Updated by neels 5 months ago

  • Status changed from New to In Progress
  • Assignee set to neels
  • % Done changed from 0 to 90

#4 Updated by neels 5 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

fix is merged

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)