Project

General

Profile

Bug #3393

SCCPlite: memory leak upon receiving xua_msg

Added by neels 2 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
07/11/2018
Due date:
% Done:

100%

Estimated time:
Spec Reference:

Description

When running osmo-bsc against an SCCPlite MSC, I see a memory leak detected by the gcc Address Sanitizer upon program exit.

First off, I discovered that libosmo-sigtran allocates xua_msg from a NULL talloc ctx, which hides this memory leak from talloc reports.
Submitted https://gerrit.osmocom.org/#/c/libosmo-sccp/+/9953 and https://gerrit.osmocom.org/#/c/osmo-bsc/+/9955 to alleviate that.

With these I see a the mem leak in the vty talloc report as well:

  xua_msg                        contains   1430 bytes in  41 blocks (ref 0) 0x60800000bf80
    struct xua_msg                 contains    103 bytes in   3 blocks (ref 0) 0x60d000023bd0
      struct xua_msg_part            contains     63 bytes in   2 blocks (ref 0) 0x60c0000615a0
        ../../../src/libosmo-sccp/src/m3ua.c:337 contains     31 bytes in   1 blocks (ref 0) 0x60c0000614e0
    struct xua_msg                 contains     40 bytes in   1 blocks (ref 0) 0x60d000023d70
    struct xua_msg                 contains    103 bytes in   3 blocks (ref 0) 0x60d0000240b0
      struct xua_msg_part            contains     63 bytes in   2 blocks (ref 0) 0x60c000062320
        ../../../src/libosmo-sccp/src/m3ua.c:337 contains     31 bytes in   1 blocks (ref 0) 0x60c000062260
    struct xua_msg                 contains     40 bytes in   1 blocks (ref 0) 0x60d000024250
    struct xua_msg                 contains    103 bytes in   3 blocks (ref 0) 0x60d000024590
      struct xua_msg_part            contains     63 bytes in   2 blocks (ref 0) 0x60c000062fe0
        ../../../src/libosmo-sccp/src/m3ua.c:337 contains     31 bytes in   1 blocks (ref 0) 0x60c000062f20
    struct xua_msg                 contains     40 bytes in   1 blocks (ref 0) 0x60d000024730
    struct xua_msg                 contains    103 bytes in   3 blocks (ref 0) 0x60d000024a70
      struct xua_msg_part            contains     63 bytes in   2 blocks (ref 0) 0x60c000063d60
        ../../../src/libosmo-sccp/src/m3ua.c:337 contains     31 bytes in   1 blocks (ref 0) 0x60c000063ca0
    struct xua_msg                 contains     40 bytes in   1 blocks (ref 0) 0x60d000024c10
    struct xua_msg                 contains    103 bytes in   3 blocks (ref 0) 0x60d000024f50
      struct xua_msg_part            contains     63 bytes in   2 blocks (ref 0) 0x60c000064ae0
        ../../../src/libosmo-sccp/src/m3ua.c:337 contains     31 bytes in   1 blocks (ref 0) 0x60c000064a20
    struct xua_msg                 contains     40 bytes in   1 blocks (ref 0) 0x60d0000250f0
    struct xua_msg                 contains    103 bytes in   3 blocks (ref 0) 0x60d000025500
      struct xua_msg_part            contains     63 bytes in   2 blocks (ref 0) 0x60c000065920
        ../../../src/libosmo-sccp/src/m3ua.c:337 contains     31 bytes in   1 blocks (ref 0) 0x60c000065860
[...]

This is arising when sending BSSMAP Reset to an SCCPlite MSC and receiving BSSMAP Reset ACK from it.

(In the code state while testing, there is still a bug where the received ACK is not seen as destined for the local osmo-bsc and sent right back to the MSC; I am not quite sure whether the mem leak comes only from that weird situation.)

In particular, this memory leak comes from m3ua_xfer_from_data()

data_part->dat = talloc_size(data_part, data_part->len);  <--- this talloc
OSMO_ASSERT(data_part->dat);
memcpy(data_part->dat, data_hdr, sizeof(*data_hdr));
memcpy(data_part->dat+sizeof(*data_hdr), data, data_len);
llist_add_tail(&data_part->entry, &xua->headers);         <--- goes into xua msg

the xua msg is then passed into m3ua_hmdc_rx_from_l2(), and passes back out e.g. via hmrt_message_for_routing(), via ipa_tx_xua_as() where it is copied.

        src = data_ie->dat + sizeof(struct m3ua_data_hdr);
        src_len = data_ie->len - sizeof(struct m3ua_data_hdr);

        /* sufficient headroom for osmo_ipa_msg_push_header() */
        msg = ipa_msg_alloc(16);
        if (!msg)
                return -1;

        dst = msgb_put(msg, src_len);
        memcpy(dst, src, src_len);

(Another code path sends it via m3ua_tx_xua_as() which calls m3ua_to_msg() and xua_to_msg(), which also copies the xua msg)

I find it rather hard to figure out the intended ownership, with the numerous msg decoding, encoding, re-encoding and copying going on in libosmo-sigtran.

Should m3ua_hmdc_rx_from_l2() deallocate the xua_msg it receives?
Should the caller of m3ua_hmdc_rx_from_l2() free it?

Callers that free xua_msg after calling m3ua_hmdc_rx_from_l2():

  • osmo_ss7_user_mtp_xfer_req()

Callers that don't:

  • m3ua_rx_xfer()
  • ipa_rx_msg_sccp()

Looks like all callers should xua_msg_free(xua) after calling m3ua_hmdc_rx_from_l2()?


Related issues

Related to OsmoBSC - Bug #2544: IPA/SCCPlite not fully supported from new osmo-bsc.gitResolved2017-10-06

History

#1 Updated by neels 2 months ago

  • Status changed from New to In Progress
  • Assignee set to neels
  • % Done changed from 0 to 90

I figured out that the caller should free the xua_msg.
This patch removes both memleaks shown above:
https://gerrit.osmocom.org/#/c/libosmo-sccp/+/9956

I also submitted more supposed memleak fixes in
https://gerrit.osmocom.org/#/c/libosmo-sccp/+/9957
https://gerrit.osmocom.org/#/c/libosmo-sccp/+/9958

#2 Updated by neels 2 months ago

  • Related to Bug #2544: IPA/SCCPlite not fully supported from new osmo-bsc.git added

#3 Updated by neels 2 months ago

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)