Actions
Bug #2922
closedheap-use-after-free osmo-msc/src/libmsc/a_iface.c:612 in a_clear_all()
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.
Updated by laforge about 6 years ago
- Assignee changed from 4368 to laforge
- % Done changed from 0 to 90
Updated by laforge about 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
merged
Actions