Project

General

Profile

Actions

Bug #2922

closed

heap-use-after-free osmo-msc/src/libmsc/a_iface.c:612 in a_clear_all()

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

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

100%

Resolution:
Spec Reference:

Description

This is detected with address sanitizer using the MSC_Tests.TC_lu_by_imei test case.

Sat Feb 10 10:09:43 2018 DMM <0002> osmo_msc.c:328 msc_subscr_conn_close(vsub=IMSI:262420000000011, cause=2): no conn fsm, releasing directly without release event.
Sat Feb 10 10:09:43 2018 DBSSAP <0010> a_iface.c:420 (subscr IMSI:262420000000011, conn_id 11) Tx BSSMAP CLEAR COMMAND to BSC
Sat Feb 10 10:09:43 2018 DLSCCP <001e> sccp_scoc.c:1642 Received unknown conn-id 11 for primitive N-DATA.request
Sat Feb 10 10:09:43 2018 DMM <0002> subscr_conn.c:243 Subscr_Conn(262420000000011)[0x612000020920]{SUBSCR_CONN_S_RELEASED}: Freeing instance
Sat Feb 10 10:09:43 2018 DMM <0002> fsm.c:318 Subscr_Conn(262420000000011)[0x612000020920]{SUBSCR_CONN_S_RELEASED}: Deallocated
=================================================================
==26386==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000003ff4 at pc 0x563f2ef1ca0f bp 0x7ffd1be55560 sp 0x7ffd1be55558
READ of size 4 at 0x614000003ff4 thread T0
    #0 0x563f2ef1ca0e in a_clear_all /home/laforge/projects/git/osmo-msc/src/libmsc/a_iface.c:612
    #1 0x563f2ef2104c in bssmap_rx_reset /home/laforge/projects/git/osmo-msc/src/libmsc/a_iface_bssap.c:120
    #2 0x563f2ef2104c in bssmap_rcvmsg_udt /home/laforge/projects/git/osmo-msc/src/libmsc/a_iface_bssap.c:166
    #3 0x563f2ef2104c in a_sccp_rx_udt /home/laforge/projects/git/osmo-msc/src/libmsc/a_iface_bssap.c:204
    #4 0x563f2ef1aecf in sccp_sap_up /home/laforge/projects/git/osmo-msc/src/libmsc/a_iface.c:579
    #5 0x7f623966ecf0 in sclc_rx_cldt /home/laforge/projects/git/libosmo-sccp/src/sccp_sclc.c:195
    #6 0x7f623966ecf0 in sccp_sclc_rx_from_scrc /home/laforge/projects/git/libosmo-sccp/src/sccp_sclc.c:260
    #7 0x7f623966dfec in scrc_node_6 /home/laforge/projects/git/libosmo-sccp/src/sccp_scrc.c:337
    #8 0x7f623966e6b1 in scrc_rx_mtp_xfer_ind_xua /home/laforge/projects/git/libosmo-sccp/src/sccp_scrc.c:459
    #9 0x7f62396715a4 in mtp_user_prim_cb /home/laforge/projects/git/libosmo-sccp/src/sccp_user.c:176
    #10 0x7f62396693e2 in m3ua_rx_xfer /home/laforge/projects/git/libosmo-sccp/src/m3ua.c:586
    #11 0x7f62396693e2 in m3ua_rx_msg /home/laforge/projects/git/libosmo-sccp/src/m3ua.c:738
    #12 0x7f62396745a2 in xua_cli_read_cb /home/laforge/projects/git/libosmo-sccp/src/osmo_ss7.c:1590
    #13 0x7f623698141a in osmo_stream_cli_read /home/laforge/projects/git/libosmo-netif/src/stream.c:192
    #14 0x7f623698141a in osmo_stream_cli_fd_cb /home/laforge/projects/git/libosmo-netif/src/stream.c:276
    #15 0x7f6239cffa70 in osmo_fd_disp_fds /home/laforge/projects/git/libosmocore/src/select.c:216
    #16 0x7f6239cffa70 in osmo_select_main /home/laforge/projects/git/libosmocore/src/select.c:256
    #17 0x563f2ef155e3 in main /home/laforge/projects/git/osmo-msc/src/osmo-msc/msc_main.c:544
    #18 0x7f6237e1ef29 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x20f29)
    #19 0x563f2ef164f9 in _start (/space/home/laforge/projects/git/osmo-msc/src/osmo-msc/osmo-msc+0xf64f9)

0x614000003ff4 is located 436 bytes inside of 440-byte region [0x614000003e40,0x614000003ff8)
freed by thread T0 here:
    #0 0x7f623a8818c8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd98c8)
    #1 0x7f623a377e82 in _talloc_free (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x3e82)

previously allocated by thread T0 here:
    #0 0x7f623a881c20 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xd9c20)
    #1 0x7f623a37a150 in _talloc_zero (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x6150)

SUMMARY: AddressSanitizer: heap-use-after-free /home/laforge/projects/git/osmo-msc/src/libmsc/a_iface.c:612 in a_clear_all
Shadow bytes around the buggy address:
  0x0c287fff87a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c287fff87b0: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa
  0x0c287fff87c0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x0c287fff87d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c287fff87e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c287fff87f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]fa
  0x0c287fff8800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff8810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff8820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff8830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff8840: fa fa fa fa fa fa fa fa fa fa 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
  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
==26386==ABORTING

It seems that the call msc_clear_request(conn, GSM48_CC_CAUSE_SWITCH_CONG); already releases + frees 'conn', at which point the subsequent conn->a.conn_id is of course referencing already-free'd memory.

What I don't get is why the handling of the A/Iu SCCP connection is not done inside the FSM. If the cleanup/destructor of the FSM would close any SCCP connection, the problem wouldn't even begin to exist.

Actions #1

Updated by laforge about 6 years ago

  • Assignee changed from 4368 to laforge
  • % Done changed from 0 to 90
Actions #2

Updated by laforge about 6 years ago

  • Status changed from New to In Progress
Actions #3

Updated by laforge about 6 years ago

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

merged

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)