[CRASH] Crash on receiving INVITE after CANCELed dialog when rtp_relay module is used

[asolovjov]

OpenSIPS version you are running

version: opensips 3.4.4 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: 036d02961
main.c compiled on 00:00:00 Feb 21 2024 with gcc 11

Crash Core Dump

gdb.txt

Describe the traffic that generated the bug

Such dialog shouldn't happen on normal life. It's happened due to some bug in Asterisk which currently I can't reproduce. For unknown reason when calling queue agent asterisk sends INVITE which looks like reINVITE (from, to tags and did in RURI) after CANCEL and ACK.
This dialog can be reproduced with sipp. So I guess anyone can crash OpenSIPS with similar configuration.
Dialog, topology_hiding and rtp_relay modules are enabled and used.
After receiving last INVITE openSIPS crashes if we use rtp_relay module. If it's not used it doesn't crash, just sends Trying.

Alice <----> OpenSIPS
INVITE ---------->
100 <----------
180 <----------
CANCEL ---------->
200 <----------
487 <----------
ACK ---------->
INVITE ---------->

Logs, opensips config and sipp scenarios are attached.

To Reproduce

Modify the attached config with your IP-address.
Start OpenSIPs
Start sipp UAS sceanrio, for example:
sipp -aa -p 5072 -i 192.168.11.204 -sf sipp_uas_canceled.xml
Start sipp UAC scenario, for example:
sipp -d 3000 -m 1 -p 5064 -sf sipp_uac_cancel_opensips_crash.xml -i 192.168.11.216 -s 34566000001 192.168.11.201 -set fromuser 345611231231
Check OpenSIPS crashed

opensips.cfg.gz
sipp_scenarios.tar.gz

Relevant System Logs

Mar 27 14:23:46.224151: INFO:[2018 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: no to-tag
Mar 27 14:23:46.224572: INFO:[2018 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: initial request
Mar 27 14:23:46.224609: INFO:[2018 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: initial request :: create NEW transaction
Mar 27 14:23:46.224640: INFO:[2018 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: change From hdr: sip:345611231231@192.168.11.216:5064 -> sip:345611231231@localhost
Mar 27 14:23:46.224671: INFO:[2018 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: change To hdr: sip:34566000001@192.168.11.201:5060 -> sip:34566000001@192.168.11.204:5072
Mar 27 14:23:46.224702: INFO:[2018 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: dialog created :: DLG_did: b2a.df7345e5 :: DLG_dir: downstream
Mar 27 14:23:46.224733: INFO:[2018 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: topology_hiding with dialog support enabled :: DLG_status: 1
Mar 27 14:23:46.224770: INFO:[2018 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: main_relay :: DLG_did: b2a.df7345e5 :: DLG_status: 1 :: request_direction: <null> :: request_type: <null>
Mar 27 14:23:46.224802: INFO:[2018 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: main_relay_branch :: T_branch_idx: 0
Mar 27 14:23:46.224832: INFO:[2018 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: main_relay_branch :: INVITE :: du: <null> : RURI: sip:34566000001@192.168.11.204:5072 : socket: udp:192.168.11.201:5060
Mar 27 14:23:46.228451: INFO:[1-60870@192.168.11.216] :: id: b2a.df7345e5 :: dialog state changed 1 to 2 :: <null>
Mar 27 14:23:49.232217: INFO:[2019 : 1-60870@192.168.11.216 : CANCEL : 345611231231 34566000001] :: no to-tag
Mar 27 14:23:49.232624: INFO:[2019 : 1-60870@192.168.11.216 : CANCEL : 345611231231 34566000001] :: CANCEL INVITE transcation processing
Mar 27 14:23:49.232678: INFO:[2019 : 1-60870@192.168.11.216 : CANCEL : 345611231231 34566000001] :: transaction exists : relaying
Mar 27 14:23:49.232739: INFO:[2019 : 1-60870@192.168.11.216 : CANCEL : 345611231231 34566000001] :: main_relay :: DLG_did: b2a.df7345e5 :: DLG_status: 2 :: request_direction: <null> :: request_type: <null>
Mar 27 14:23:49.234266: INFO:[2018 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: failure route
Mar 27 14:23:49.234497: INFO:[2018 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: transaction was cancelled by UAC
Mar 27 14:23:49.236281: INFO:[1-60870@192.168.11.216] :: id: b2a.df7345e5 :: dialog state changed 2 to 5 :: <null>
Mar 27 14:23:49.236560: INFO:[2019 : 1-60870@192.168.11.216 : ACK : 345611231231 34566000001] :: has_totag : sequential request withing a dialog. Trying dialog match
Mar 27 14:23:49.236596: INFO:[2019 : 1-60870@192.168.11.216 : ACK : 345611231231 34566000001] :: topology_hiding matched :: callee callid: DLGCH_VV5AVAoEUTNVAAJHAwcLRVtdQFNCUg--
Mar 27 14:23:49.236627: INFO:[2019 : 1-60870@192.168.11.216 : ACK : 345611231231 34566000001] :: main_relay :: DLG_did: b2a.df7345e5 :: DLG_status: 5 :: request_direction: <null> :: request_type: <null>
Mar 27 14:23:49.237635: INFO:[2019 : 1-60870@192.168.11.216 : INVITE : 345611231231 34566000001] :: has_totag : sequential request withing a dialog. Trying dialog match
Mar 27 14:23:49.237687: WARNING:dialog:log_next_state_dlg: bogus event 8 in state 5 for dlg 0x7ff8b0ffb8c0 [2603:1582577661] with clid '1-60870@192.168.11.216' and tags '60870SIPpTag001' '650734SIPpTag011'
Mar 27 14:23:49.237731: CRITICAL:core:sig_usr: segfault in process pid: 2019, id: 11

OS/environment information

• Operating System: AlmaLinux 9.3
• OpenSIPS installation: opensips-3.4.4-1.el9.x86_64>

Additional context

[asolovjov]

This is probably related to #3343 that dialogs stay in memory. It doesn't metter when you send last INVITE after cancelled call, having headers for dialog identification is enough.
It crashes while executing match_dialog function.

[github-actions]

Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days.

[github-actions]

Marking as closed due to lack of progress for more than 30 days. If this issue is still relevant, please re-open it with additional details.