Project

General

Profile

Bug #4646

SEGV when bringing up Nokia InSite

Added by laforge over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
libosmogsm
Target version:
-
Start date:
07/04/2020
Due date:
% Done:

100%

Spec Reference:

Description

This is with "OpenBSC version 1.3.2.3-e811" and current libosmocore/libosmo-abis

root@sysmo-e1-tracer:~/git/openbsc/openbsc/src/osmo-nitb# LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.5  ./osmo-nitb -c ./openbsc-insite.cfg 
<001e> telnet_interface.c:104 Available via telnet 127.0.0.1 4242
<001f> input/lapd.c:251 (0:1-T1-S62): LAPD Allocating SAP for SAPI=62 / TEI=1 (dl=0x615000001500, sap=0x6150000014e0)
<001f> input/lapd.c:261 (0:1-T1-S62): k=1 N200=3 N201=260 T200=1.0 T203=10.0
<001f> input/lapd.c:524 (0:1-T1-S62): LAPD DL-ESTABLISH request TEI=1 SAPI=62
<0025> control_if.c:911 CTRL at 127.0.0.1 4249
DB: Database initialized.
DB: Database prepared.
<001f> input/lapd.c:660 ((0:1-T1-S62)) LAPD DL-ESTABLISH confirm TEI=1 SAPI=62
<0005> bts_nokia_site.c:56 bootstrapping OML for BTS 0
Getting attributes from BTS0 type nokia_site is not supported.
Getting attributes from BTS0 type nokia_site is not supported.
<0005> bts_nokia_site.c:1677 ABIS_OM_MDISC_FOM
<0005> bts_nokia_site.c:1505 (0x81) NOKIA_BTS_ACK
<0005> bts_nokia_site.c:1537 ACK = 1
<001f> input/lapd.c:551 (0:1-T1-S62): LAPD DL-RELEASE request TEI=1 SAPI=62
<001f> input/lapd.c:664 ((0:1-T1-S62)) LAPD DL-RELEASE confirm TEI=1 SAPI=62
<001f> input/lapd.c:289 (0:1-T1-S62): LAPD Freeing SAP for SAPI=62 / TEI=1 (dl=0x615000001500, sap=0x6150000014e0)
AddressSanitizer:DEADLYSIGNAL
=================================================================
==28749==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f399d918633 bp 0x61600000b1e0 sp 0x7ffe298a0580 T0)
==28749==The signal is caused by a READ memory access.
==28749==Hint: address points to the zero page.
    #0 0x7f399d918632 in lapd_send_i src/gsm/lapd_core.c:1797
    #1 0x7f399d91b167 in lapd_rx_i src/gsm/lapd_core.c:1601
    #2 0x7f399d91b167 in lapd_ph_data_ind src/gsm/lapd_core.c:1642
    #3 0x7f399d7c787e in lapd_receive input/lapd.c:501
    #4 0x7f399d79a167 in e1inp_rx_ts_lapd /root/git/libosmo-abis/src/e1_input.c:708
    #5 0x7f399d7efd1f in handle_ts1_read input/dahdi.c:194
    #6 0x7f399d7efd1f in dahdi_fd_cb input/dahdi.c:484
    #7 0x7f399d8c54f3 in osmo_fd_disp_fds src/select.c:227
    #8 0x7f399d8c54f3 in _osmo_select_main src/select.c:265
    #9 0x7f399d8c5c05 in osmo_select_main src/select.c:274
    #10 0x563d2ab5335b in main /root/git/openbsc/openbsc/src/osmo-nitb/bsc_hack.c:400
    #11 0x7f399d32a09a in __libc_start_main ../csu/libc-start.c:308
    #12 0x563d2ab535d9 in _start (/root/git/openbsc/openbsc/src/osmo-nitb/osmo-nitb+0x125d9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV src/gsm/lapd_core.c:1797 in lapd_send_i
==28749==ABORTING

Related issues

Related to libosmocore - Bug #1982: LAPD: segfault in lapd_est_req functionResolved03/14/2017

Related to libosmocore - Bug #1760: LAPD: segfault in T200 call-backClosed07/03/2016

Related to OsmoBSC - Bug #1761: LAPD: segfault when bootstrapping Nokia InSiteResolved07/03/2016

Associated revisions

Revision bc1d7152 (diff)
Added by laforge over 1 year ago

lapd_core: After calling into L3, check if the state has changed

While processing an I-frame we may deliver its payload to L3. After
returning from L3 procesing, we run some additional code, assuming
the LAPD/DL state has not changed meanwhile.

However, if the application destroys the LAPD/DL meanwhile, our state
might be NULL again, and in this state we should not perform any further
action.

This is one of the cases where synchronous in-line dispatch across
various layers is hitting us. L3 should have an input queue, and only
start processing after all L2 work has completed and we're about to go
back to sleep in select().

Change-Id: I026b64503511002c13c0f4117648c366c48ecc62
Related: OS#1761
Closes: OS#4646

History

#1 Updated by laforge over 1 year ago

  • Related to Bug #1982: LAPD: segfault in lapd_est_req function added

#2 Updated by laforge over 1 year ago

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7168633 in lapd_send_i (line=line@entry=1601, lctx=<optimized out>, lctx=<optimized out>)
    at lapd_core.c:1797
1797    lapd_core.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7168633 in lapd_send_i (line=line@entry=1601, lctx=<optimized out>, lctx=<optimized out>)
    at lapd_core.c:1797
#1  0x00007ffff716b168 in lapd_rx_i (lctx=0x7fffffffe4a0, msg=0x61600000b1e0) at lapd_core.c:1601
#2  lapd_ph_data_ind (msg=msg@entry=0x61600000b1e0, lctx=lctx@entry=0x7fffffffe4a0) at lapd_core.c:1642
#3  0x00007ffff701787f in lapd_receive (li=<optimized out>, msg=msg@entry=0x61600000b1e0, 
    error=error@entry=0x7fffffffe570) at input/lapd.c:501
#4  0x00007ffff6fea168 in e1inp_rx_ts_lapd (e1i_ts=e1i_ts@entry=0x62f0000004b0, 
    msg=msg@entry=0x61600000b1e0) at e1_input.c:708
#5  0x00007ffff703fd20 in handle_ts1_read (bfd=0x62f000000a50) at input/dahdi.c:194
#6  dahdi_fd_cb (bfd=0x62f000000a50, what=<optimized out>) at input/dahdi.c:484
#7  0x00007ffff71154f4 in osmo_fd_disp_fds (_eset=<optimized out>, _wset=<optimized out>, 
    _rset=<optimized out>) at select.c:227
#8  _osmo_select_main (polling=0) at select.c:265
#9  0x00007ffff7115c06 in osmo_select_main (polling=<optimized out>) at select.c:274
#10 0x000055555556635c in main (argc=3, argv=0x7fffffffea18) at bsc_hack.c:400
(gdb) frame 1
#1  0x00007ffff716b168 in lapd_rx_i (lctx=0x7fffffffe4a0, msg=0x61600000b1e0) at lapd_core.c:1601
1601    in lapd_core.c
(gdb) p dl->tx_hist
$4 = (struct lapd_history *) 0x0

#3 Updated by laforge over 1 year ago

I somehow have a deja-vu. Didn't we fix this kind of bug already at some point? The order of events appears to be:
  • we receive an I-frame on an established LAPD data link (MF_EST)
  • we are somewhere in lapd_rx_i() from where we dispatch the frame to the application (L3 and higher)
  • while in that call-back, the application decised to destroy the data link (DL-RELEASE.req)
  • after processing that, we resume processing in lapd_rx_i()

#4 Updated by laforge over 1 year ago

laforge wrote:

I somehow have a deja-vu. Didn't we fix this kind of bug already at some point?

See #1760 + https://gerrit.osmocom.org/c/libosmocore/+/451

#5 Updated by laforge over 1 year ago

  • Related to Bug #1760: LAPD: segfault in T200 call-back added

#6 Updated by laforge over 1 year ago

  • Related to Bug #1761: LAPD: segfault when bootstrapping Nokia InSite added

#7 Updated by laforge over 1 year ago

  • Assignee set to laforge
  • % Done changed from 0 to 20

ok #1761 is the exact duplicate. We just fixed it in osmo-bsc but not in osmo-nitb.

#8 Updated by laforge over 1 year ago

  • % Done changed from 20 to 60

proposed fix in https://gerrit.osmocom.org/c/libosmocore/+/19130 - it is the only situation where we do anything after dispatching a L3 payload up the stack.

#9 Updated by laforge over 1 year ago

  • Project changed from OsmoNITB to libosmocore
  • Category set to libosmogsm
  • Status changed from New to In Progress
  • % Done changed from 60 to 90

patch confirmed to fix the problem on an InSite.

#10 Updated by laforge over 1 year ago

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

merged

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)