Summary: | ASTERISK-24528: res_pjsip_refer: Sending INVITE with Replaces in-dialog with invalid target causes crash | ||
Reporter: | Joshua C. Colp (jcolp) | Labels: | Security |
Date Opened: | 2014-11-17 09:03:16.000-0600 | Date Closed: | 2014-11-20 09:48:11.000-0600 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Resources/res_pjsip_refer |
Versions: | 12.7.0 13.0.0 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | Attachments: | ||
Description: | The INVITE with Replaces handling within res_pjsip_refer does not currently completely handle the case where a channel may already be handled by another thread. If an off nominal case occurs the code will incorrectly hang up the channel causing the other thread handling the channel to be using an already hung up and possibly freed channel.
Much FRACKING occurs. | ||
Comments: | By: Matt Jordan (mjordan) 2014-11-17 10:43:18.994-0600 [~jcolp]: I can't recall - did we have a specific scenario in mind that caused this? By: Joshua C. Colp (jcolp) 2014-11-17 10:48:54.938-0600 It came up during fuzz testing. It's easily reproducible with a SIPP scenario. Send a normal INVITE, have the dialplan answer/playback/whatever. Then send an INVITE with Replaces and have the Replaces not match anything. Crash. By: Matt Jordan (mjordan) 2014-11-17 13:34:01.681-0600 Cool. We should probably have a test for this then once it goes in. By: Joshua C. Colp (jcolp) 2014-11-17 13:45:30.008-0600 Agreed! Very doable. |