SCTP ABORT packets with no cause padding causes a decode failure - slice bounds out of range
- Dominant language
- Go
- Stars
- 6.8k
- Forks
- 1.2k
- PR merge metrics
- No merged PRs in 30d
Description
I hit this issue when an SCTP client i was using sent an ABORT packet to my application using gopacket. This is what the abort packet looks like:

The issue here is as you can see there is no cause padding for the protocol violation cause as it is the only cause that is present and the ABORT chunk already has a chunk padding . In this case the ABORT chunk is handled by the decodeSCTPError function in sctp.go. This function takes the chunk and decodes all the parameter data. When it get s the paramData slice, it uses the "sc.Length" which is the length of the chunk without padding and it then calls the decodeSCTPParameter which then adds the padding to the cause thus causing it to run out of bounds. This is the code:
`paramData := data[4:sc.Length]
for len(paramData) > 0 {
p := SCTPErrorParameter(decodeSCTPParameter(paramData))
paramData = paramData[p.ActualLength:]
sc.Parameters = append(sc.Parameters, p)
}
`
And decodeSCTPParameter does:
`paramData := data[4:sc.Length]
for len(paramData) > 0 {
p := SCTPErrorParameter(decodeSCTPParameter(paramData))
paramData = paramData[p.ActualLength:]
sc.Parameters = append(sc.Parameters, p)
}
`
Which from the above packet trace rounds up 46 to 48 whereas the paramData slice is only 46 bytes.
The fix here is to just use the ActualLength when constructing the paramData which is how i got around this issue. A similar change also needs to be done for the decodeSCTPHeartbeat function.
Contributor guide
Assessment
This issue has not been assessed yet.