Bug #3390
closedvty segfaults when two commands "foo [<0-23>]" and "foo <0-23> bar" coexist
100%
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.
Updated by neels almost 6 years 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
Updated by neels almost 6 years 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)
Updated by neels almost 6 years ago
- Status changed from New to In Progress
- Assignee set to neels
- % Done changed from 0 to 90
Fix in https://gerrit.osmocom.org/#/c/libosmocore/+/9939 ,
depends on two cosmetic preparations https://gerrit.osmocom.org/#/c/libosmocore/+/9937 and https://gerrit.osmocom.org/#/c/libosmocore/+/9938
Updated by neels almost 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
fix is merged