Bug #2863
closed
osmo-mgw segfaults on DLCX (use-after-free in mgcp_network.c)
Added by dexter over 6 years ago.
Updated about 6 years ago.
Description
In mgcp_network.c in mgcp_dispatch_rtp_bridge_cb() we use conn->priv to store the pointer to the opposite connection so we do not need to iterate through the connection list once more. When someone frees the opposite connection using a DLCX, then the pointer points to already freed memory. We need some mechanism to invalidate that information on DLCX, so that the callback function can know and prevent the use-after-free.
- Status changed from New to In Progress
- % Done changed from 0 to 100
do we have a test case that can provoke the problem in the old code and which can
show that the new code with this fix is fixed? Please make sure we try to write
tests before developing fixes or new features.
We should definitely have a TTCN3 testcase for this problem. I think of the following:
- 2 times CRCX on the same endpoint to create the two connections.
- Send one RTP packet to connection #1 to trigger the mechanism that finds the opposite connection.
- send DLCX to remove connection #2
(Now the pointer that is stored in conn->priv points to unallocated memory)
- Send one RTP packet to connection #1, osmo-mgw should segfault.
I know now how to create and delete connections in TTCN3 as I have already done some suitcases do that, but I do not know how to send RTP packets. From what I can see we do not send any RTP packets from the mgw testsuite at the moment.
On Mon, Feb 05, 2018 at 10:39:00PM +0000, dexter [REDMINE] wrote:
I know now how to create and delete connections in TTCN3 as I have already done some suitcases do that, but I do not know how to send RTP packets. From what I can see we do not send any RTP packets from the mgw testsuite at the moment.
I have implemented library/RTP_Emulation.ttcn for this purpose in
December. It implements sendonly/recvonly/sendrecv modes and will send
some 'plausible' RTP (timestamp/payload/seq_nr) with static payload.
It doesn't yet implement actual validation, i.e. there's no provision to
check that the number of packets received matches some expected value,
or that their payload matches.
RTP_Emulation.ttcn is not yet used by any of our test suites.
- Status changed from In Progress to Resolved
Also available in: Atom
PDF
