Osmocom Libraries » libosmo-sccp + libosmo-sigtran

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()?