Project

General

Profile

Actions

Bug #3092

closed

osmo-bts-virtual crash when sending received pdch over gsmtap

Added by pespin about 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
osmo-bts-virtual
Target version:
-
Start date:
03/21/2018
Due date:
% Done:

100%

Spec Reference:

Description

While running latest osmo-bts-virtual with osmo-bsc, osmo-msc, etc. and virtphy (fixeria/trx branch) + ttcn3 PCU_TestsC_ul_tbf.
I can reproduce each time the test is run.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6234ec3 in __memmove_sse2_unaligned_erms () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff6234ec3 in __memmove_sse2_unaligned_erms () from /usr/lib/libc.so.6
#1  0x00007ffff6dbf4c8 in gsmtap_makemsg_ex (type=<optimized out>, arfcn=arfcn@entry=17255, ts=ts@entry=6 '\006',
    chan_type=<optimized out>, ss=ss@entry=0 '\000', fn=fn@entry=11249, signal_dbm=0 '\000', snr=0 '\000',
    data=0x5555557d5b50 "", len=4294967263) at /home/pespin/dev/sysmocom/git/libosmocore/src/gsmtap_util.c:179
#2  0x00007ffff6dbf6d8 in gsmtap_send_ex (gti=0x555555877f10, type=type@entry=1 '\001', arfcn=arfcn@entry=17255,
    ts=ts@entry=6 '\006', chan_type=<optimized out>, ss=<optimized out>, fn=11249, signal_dbm=0 '\000', snr=0 '\000',
    data=0x5555557d5b50 "", len=4294967263) at /home/pespin/dev/sysmocom/git/libosmocore/src/gsmtap_util.c:311
#3  0x00007ffff6dbf765 in gsmtap_send (gti=<optimized out>, arfcn=arfcn@entry=17255, ts=ts@entry=6 '\006',
    chan_type=<optimized out>, ss=<optimized out>, fn=fn@entry=11249, signal_dbm=0 '\000', snr=0 '\000',
    data=0x5555557d5b50 "", len=4294967263) at /home/pespin/dev/sysmocom/git/libosmocore/src/gsmtap_util.c:330
#4  0x0000555555573571 in to_gsmtap (trx=0x7ffff7ef8070, l1sap=0x7fffffffde80)
    at /home/pespin/dev/sysmocom/git/osmo-bts/src/common/l1sap.c:397
#5  0x0000555555573b9c in l1sap_up (trx=0x7ffff7ef8070, l1sap=l1sap@entry=0x7fffffffde80)
    at /home/pespin/dev/sysmocom/git/osmo-bts/src/common/l1sap.c:1285
#6  0x000055555555ec06 in virt_um_rcv_cb (vui=<optimized out>, msg=<optimized out>)
    at /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-virtual/l1_if.c:170
#7  0x000055555555f5c6 in virt_um_fd_cb (ofd=0x55555587cc30, what=<optimized out>)
    at /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-virtual/virtual_um.c:50
#8  0x00007ffff6db6991 in osmo_fd_disp_fds (_eset=0x7fffffffe090, _wset=0x7fffffffe010, _rset=0x7fffffffdf90)
    at /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:216
#9  osmo_select_main (polling=polling@entry=0) at /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:256
#10 0x0000555555576fbc in bts_main (argc=5, argv=0x7fffffffe288)
    at /home/pespin/dev/sysmocom/git/osmo-bts/src/common/main.c:364
#11 0x00007ffff61b5f4a in __libc_start_main () from /usr/lib/libc.so.6
#12 0x000055555555c4ca in _start ()

Hits this new OSMO_ASSERT added:

index 0a229e1b..f2593142 100644
--- a/src/common/l1sap.c
+++ b/src/common/l1sap.c
@@ -282,6 +282,7 @@ static int gsmtap_pdch(struct osmo_phsap_prim *l1sap, uint8_t *chan_type,

        *data = msg->data + sizeof(struct osmo_phsap_prim);
        *len = msg->len - sizeof(struct osmo_phsap_prim);
+       OSMO_ASSERT(*len >= 0);

        if (L1SAP_IS_PTCCH(fn)) {
                *chan_type = GSMTAP_CHANNEL_PTCCH;

Here the backtrace once the assert is in place and being hit:

Assert failed *len >= 0 /home/pespin/dev/sysmocom/git/osmo-bts/src/common/l1sap.c:286
backtrace() returned 9 addresses
/home/pespin/dev/sysmocom/build/new/out/bin/osmo-bts-virtual(+0x1f6fa) [0x5555555736fa]
/home/pespin/dev/sysmocom/build/new/out/bin/osmo-bts-virtual(+0x1fc3c) [0x555555573c3c]
/home/pespin/dev/sysmocom/build/new/out/bin/osmo-bts-virtual(+0xac06) [0x55555555ec06]
/home/pespin/dev/sysmocom/build/new/out/bin/osmo-bts-virtual(+0xb5c6) [0x55555555f5c6]
/home/pespin/dev/sysmocom/build/new/out/lib/libosmocore.so.9(osmo_select_main+0x1d1) [0x7ffff6db6991]
/home/pespin/dev/sysmocom/build/new/out/bin/osmo-bts-virtual(+0x2305c) [0x55555557705c]
/usr/lib/libc.so.6(__libc_start_main+0xea) [0x7ffff61b5f4a]
/home/pespin/dev/sysmocom/build/new/out/bin/osmo-bts-virtual(+0x84ca) [0x55555555c4ca]

Program received signal SIGABRT, Aborted.
0x00007ffff61c9860 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff61c9860 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff61caec9 in abort () from /usr/lib/libc.so.6
#2  0x00005555555736ff in gsmtap_pdch (l1sap=0x7fffffffde80,
    l1sap=0x7fffffffde80, len=<synthetic pointer>, data=<synthetic pointer>,
    fn=3133, ss=<synthetic pointer>, chan_type=<synthetic pointer>)
    at /home/pespin/dev/sysmocom/git/osmo-bts/src/common/l1sap.c:286
#3  to_gsmtap (trx=0x7ffff7ef8070, l1sap=0x7fffffffde80)
    at /home/pespin/dev/sysmocom/git/osmo-bts/src/common/l1sap.c:367
#4  0x0000555555573c3c in l1sap_up (trx=0x7ffff7ef8070,
    l1sap=l1sap@entry=0x7fffffffde80)
    at /home/pespin/dev/sysmocom/git/osmo-bts/src/common/l1sap.c:1288
#5  0x000055555555ec06 in virt_um_rcv_cb (vui=<optimized out>,
    msg=<optimized out>)
    at /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-virtual/l1_if.c:170
#6  0x000055555555f5c6 in virt_um_fd_cb (ofd=0x55555587cc30,
    what=<optimized out>)
    at /home/pespin/dev/sysmocom/git/osmo-bts/src/osmo-bts-virtual/virtual_um.c:50
#7  0x00007ffff6db6991 in osmo_fd_disp_fds (_eset=0x7fffffffe090,
    _wset=0x7fffffffe010, _rset=0x7fffffffdf90)
    at /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:216
#8  osmo_select_main (polling=polling@entry=0)
    at /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:256
---Type <return> to continue, or q <return> to quit---
#9  0x000055555557705c in bts_main (argc=5, argv=0x7fffffffe288)
    at /home/pespin/dev/sysmocom/git/osmo-bts/src/common/main.c:364
#10 0x00007ffff61b5f4a in __libc_start_main () from /usr/lib/libc.so.6
#11 0x000055555555c4ca in _start ()

So, what I found until now:
It seems gsmtap_pdch() assumes osmo_phsap_prim was allocated at the start of the msgb, and it basically removes it before sending it to gsmtap code. It seems however when the l1sap is created in virt_um_rcv_cb(), it is not allocated inside the msgb but in the stack. As a result, the msgb->len is not sizeof(osmo_phsap_prim) + payload, but only payload. When sizeof(osmo_phsap_prim) is substracted in gsmtap_pdch(), a negative value is returned which ends up converted into a really big value when casted to unsigned int.

I still need to find the best way to fix it. Most probably the l1sap primitive needs to be moved to the start of the msgb buffer as it is done in other bts models.

Actions #1

Updated by pespin about 6 years ago

  • Status changed from New to Feedback

Patch available fixing the issue: https://gerrit.osmocom.org/#/c/7429/

I have another patch set which also works that changes osmo-bts-virtual to allocate the l1sap at the headroom of the msgb coming from gsmtap, but I think the patch announced above is a better fix as it doesn't constrain where lower layers allocate the l1sap struct.

I only tested it on an osmo-bts-virtual so far.
We need to check that all bts models are setting l2h before calling l1sap_up (only required if msgb!=NULL of course).

Actions #2

Updated by pespin about 6 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

Merged

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)