Fragmented ordered user messages with inconsistent stream sequence numbers are accepted and delivere

[Julian Cordes <julian.cordes@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

When fragmented ordered user messages are sent to the linux kernel user
messages with inconsistent stream sequence numbers are accepted and
delivered to the application. Take for example an look at the following test case:
https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/error-cases/packet-loss/ordered/ordered-packet-loss-2.pkt

Here I first inject two DATA-Chunks with sid/ssn 1/1, 2/1 into the
kernel with packetdrill:
line 67: +0.0 < sctp: DATA[flgs=E, len=1016, tsn=2, sid=1, ssn=1,
ppid=0]
line 69: +0.1 < sctp: DATA[flgs=E, len=1016, tsn=4, sid=2, ssn=1,
ppid=0]

After 0.1 seconds i then inject an FORWARD-TSN with cum_tsn=2 bundled
with an DATA-Chunk that looks like this:
DATA[flgs=B, len=1016, tsn=3, sid=2, ssn=0, ppid=0]

This "looks" like the first segment of the user message where already a
fragment (tsn=4) was received. But the ssn-values are  not consistent.
The DATA-Chunk with tsn=3 has ssn=0 and the ssn=1 therefore they should
be ignored by the IUT and not be delivered to the userland application when
calling sctp_recvmsg. Unfortunatly the linux kernel implementation does
currently deliver these inconsistent user messages.

There are many test-cases that all reproduce this
issue. Just take a look at the README at
https://github.com/nplab/PR_SCTP_Testsuite/tree/master/forward-tsn/error-cases/packet-loss/ordered.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]