An issue was discovered in Sangoma Asterisk 16.x before 16.16.1, 17.x before 17.9.2, and 18.x before 18.2.1 and Certified Asterisk before 16.8-cert6. When re-negotiating for T.38, if the initial remote response was delayed just enough, Asterisk would send both audio and T.38 in the SDP. If this happened, and the remote responded with a declined T.38 stream, then Asterisk would crash.
{
"versions": [
{
"introduced": "16.0.0"
},
{
"fixed": "16.16.1"
},
{
"introduced": "17.0.0"
},
{
"fixed": "17.9.2"
},
{
"introduced": "18.0"
},
{
"fixed": "18.2.1"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-NA"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-cert1\\-rc1"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-cert1\\-rc2"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-cert1\\-rc3"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-cert1\\-rc4"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-cert2"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-cert3"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-cert4"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-cert4\\-rc1"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-cert4\\-rc2"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-cert4\\-rc3"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-cert4\\-rc4"
},
{
"introduced": "0"
},
{
"last_affected": "16.8-cert5"
}
]
}