lwn.git/include/net/sctp/sm.h, branch v2.6.33.1-rt10

sctp: Fix malformed "Invalid Stream Identifier" error

2009-11-23T20:53:56+00:00

The "Invalid Stream Identifier" error has a 16 bit reserved field at the end, thus making the parameter length be 8 bytes. We've never supplied that reserved field making wireshark tag the packet as malformed. Reported-by: Chris Dischino Signed-off-by: Vlad Yasevich

sctp: Fix to handle SHUTDOWN in SHUTDOWN_RECEIVED state

2008-10-23T08:01:18+00:00

Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT send a SHUTDOWN in response to a ULP request. The Cumulative TSN Ack of the received SHUTDOWN chunk MUST be processed. This patch fix to process Cumulative TSN Ack of the received SHUTDOWN chunk in SHUTDOWN_RECEIVED state. Signed-off-by: Wei Yongjun Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller

sctp: Fix kernel panic while process protocol violation parameter

2008-09-30T12:32:24+00:00

Since call to function sctp_sf_abort_violation() need paramter 'arg' with 'struct sctp_chunk' type, it will read the chunk type and chunk length from the chunk_hdr member of chunk. But call to sctp_sf_violation_paramlen() always with 'struct sctp_paramhdr' type's parameter, it will be passed to sctp_sf_abort_violation(). This may cause kernel panic. sctp_sf_violation_paramlen() |-- sctp_sf_abort_violation() |-- sctp_make_abort_violation() This patch fixed this problem. This patch also fix two place which called sctp_sf_violation_paramlen() with wrong paramter type. Signed-off-by: Wei Yongjun Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller

[SCTP]: Remove sctp_add_cmd_sf wrapper bloat

2008-03-28T00:54:29+00:00

With a was number of callsites sctp_add_cmd_sf wrapper bloats kernel by some amount. Due to unlikely tracking allyesconfig, with the initial result were around ~7kB (thus caught my attention) while a non-debug config produced only ~2.3kB effect. I (ij) proposed first a patch to uninline it but Vlad responded with a patch that removed the only sctp_add_cmd call which is wrapped by sctp_add_cmd_sf (I wasn't sure if I could do that). I did minor cleanup to Vlad's patch. Signed-off-by: Ilpo Järvinen Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller

[SCTP]: Stop claiming that this is a "reference implementation"

2008-02-05T15:59:07+00:00

I was notified by Randy Stewart that lksctp claims to be "the reference implementation". First of all, "the refrence implementation" was the original implementation of SCTP in usersapce written ty Randy and a few others. Second, after looking at the definiton of 'reference implementation', we don't really meet the requirements. Signed-off-by: Vlad Yasevich

[SCTP]: Implement the receive and verification of AUTH chunk

2007-10-10T23:51:31+00:00

This patch implements the receive path needed to process authenticated chunks. Add ability to process the AUTH chunk and handle edge cases for authenticated COOKIE-ECHO as well. Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller

[SCTP]: Enable the sending of the AUTH chunk.

2007-10-10T23:51:31+00:00

SCTP-AUTH, Section 6.2: Endpoints MUST send all requested chunks authenticated where this has been requested by the peer. The other chunks MAY be sent authenticated or not. If endpoint pair shared keys are used, one of them MUST be selected for authentication. To send chunks in an authenticated way, the sender MUST include these chunks after an AUTH chunk. This means that a sender MUST bundle chunks in order to authenticate them. If the endpoint has no endpoint pair shared key for the peer, it MUST use Shared Key Identifier 0 with an empty endpoint pair shared key. If there are multiple endpoint shared keys the sender selects one and uses the corresponding Shared Key Identifier Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller

SCTP : Add paramters validity check for ASCONF chunk

2007-09-26T05:55:49+00:00

If ADDIP is enabled, when an ASCONF chunk is received with ASCONF paramter length set to zero, this will cause infinite loop. By the way, if an malformed ASCONF chunk is received, will cause processing to access memory without verifying. This is because of not check the validity of parameters in ASCONF chunk. This patch fixed this. Signed-off-by: Wei Yongjun Signed-off-by: Vlad Yasevich

SCTP: Clean up OOTB handling and fix infinite loop processing

2007-09-26T05:55:47+00:00

While processing OOTB chunks as well as chunks with an invalid length of 0, it was possible to SCTP to get wedged inside an infinite loop because we didn't catch the condition correctly, or didn't mark the packet for discard correctly. This work is based on original findings and work by Wei Yongjun Signed-off-by: Vlad Yasevich

SCTP: Fix to encode PROTOCOL VIOLATION error cause correctly

2007-08-30T17:50:48+00:00

PROTOCOL VIOLATION error cause in ABORT is bad encode when make abort chunk. When SCTP encode ABORT chunk with PROTOCOL VIOLATION error cause, it just add the error messages to PROTOCOL VIOLATION error cause, the rest four bytes(struct sctp_paramhdr) is just add to the chunk, not change the length of error cause. This cause the ABORT chunk to be a bad format. The chunk is like this: ABORT chunk Chunk type: ABORT (6) Chunk flags: 0x00 Chunk length: 72 (*1) Protocol violation cause Cause code: Protocol violation (0x000d) Cause length: 62 (*2) Cause information: 5468652063756D756C61746976652074736E2061636B2062... Cause padding: 0000 [Needless] 00030010 Chunk Length(*1) = 72 but Cause length(*2) only 62, not include the extend 4 bytes. ((72 - sizeof(chunk_hdr)) = 68) != (62 +3) / 4 * 4 Signed-off-by: Wei Yongjun Signed-off-by: Vlad Yasevich