linux-toradex.git/net/sctp, branch v2.6.16.48

SCTP: Always linearise packet on input

2006-11-29T11:06:04+00:00

I was looking at a RHEL5 bug report involving Xen and SCTP
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212550).
It turns out that SCTP wasn't written to handle skb fragments at
all.  The absence of any calls to skb_may_pull is testament to
that.

It just so happens that Xen creates fragmented packets more often
than other scenarios (header & data split when going from domU to
dom0).  That's what caused this bug to show up.

Until someone has the time sits down and audits the entire net/sctp
directory, here is a conservative and safe solution that simply
linearises all packets on input.

Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

Fix sctp_primitive_ABORT() call in sctp_close()

2006-09-05T19:59:11+00:00

With the recent fix, the callers of sctp_primitive_ABORT()
need to create an ABORT chunk and pass it as an argument rather
than msghdr that was passed earlier.

Adrian Bunk:
Ported to 2.6.16.

Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

SCTP: Send only 1 window update SACK per message.

2006-08-26T00:41:37+00:00

Right now, every time we increase our rwnd by more then MTU bytes, we
trigger a SACK.  When processing large messages, this will generate a
SACK for almost every other SCTP fragment. However since we are freeing
the entire message at the same time, we might as well collapse the SACK
generation to 1.

Signed-off-by: Tsutomu Fujii 
Signed-off-by: Vlad Yasevich 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

SCTP: Reset rtt_in_progress for the chunk when processing its sack.

2006-08-26T00:41:12+00:00

Signed-off-by: Vlad Yasevich 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

SCTP: Limit association max_retrans setting in setsockopt.

2006-08-26T00:40:29+00:00

When using ASSOCINFO socket option, we need to limit the number of
maximum association retransmissions to be no greater than the sum
of all the path retransmissions. This is specified in Section 7.1.2
of the SCTP socket API draft.
However, we only do this if the association has multiple paths. If
there is only one path, the protocol stack will use the
assoc_max_retrans setting when trying to retransmit packets.

Signed-off-by: Vlad Yasevich 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

SCTP: Fix persistent slowdown in sctp when a gap ack consumes rx buffer.

2006-08-26T00:39:48+00:00

In the event that our entire receive buffer is full with a series of
chunks that represent a single gap-ack, and then we accept a chunk
(or chunks) that fill in the gap between the ctsn and the first gap,
we renege chunks from the end of the buffer, which effectively does
nothing but move our gap to the end of our received tsn stream. This
does little but move our missing tsns down stream a little, and, if the
sender is sending sufficiently large retransmit frames, the result is a
perpetual slowdown which can never be recovered from, since the only
chunk that can be accepted to allow progress in the tsn stream necessitates
that a new gap be created to make room for it. This leads to a constant
need for retransmits, and subsequent receiver stalls. The fix I've come up
with is to deliver the frame without reneging if we have a full receive
buffer and the receiving sockets sk_receive_queue is empty(indicating that
the receive buffer is being blocked by a missing tsn).

Signed-off-by: Neil Horman 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

SCTP: Reject sctp packets with broadcast addresses.

2006-08-26T00:39:03+00:00

Make SCTP handle broadcast properly

Signed-off-by: Vlad Yasevich 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Adrian Bunk

Fix sctp privilege elevation (CVE-2006-3745)

2006-08-23T16:01:55+00:00

sctp_make_abort_user() now takes the msg_len along with the msg
so that we don't have to recalculate the bytes in iovec.
It also uses memcpy_fromiovec() so that we don't go beyond the
length allocated.

It is good to have this fix even if verify_iovec() is fixed to
return error on overflow.

Signed-off-by: Sridhar Samudrala 
Acked-by: David Miller 
Signed-off-by: Adrian Bunk

[PATCH] SCTP: Validate the parameter length in HB-ACK chunk (CVE-2006-1857)

2006-05-20T22:00:34+00:00

If SCTP receives a badly formatted HB-ACK chunk, it is possible
that we may access invalid memory and potentially have a buffer
overflow.  We should really make sure that the chunk format is
what we expect, before attempting to touch the data.

Signed-off-by: Vlad Yasevich 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: Chris Wright

[PATCH] SCTP: Prevent possible infinite recursion with multiple bundled DATA. (CVE-2006-2274)

2006-05-09T19:53:21+00:00

There is a rare situation that causes lksctp to go into infinite recursion
and crash the system.  The trigger is a packet that contains at least the
first two DATA fragments of a message bundled together. The recursion is
triggered when the user data buffer is smaller that the full data message.
The problem is that we clone the skb for every fragment in the message.
When reassembling the full message, we try to link skbs from the "first
fragment" clone using the frag_list. However, since the frag_list is shared
between two clones in this rare situation, we end up setting the frag_list
pointer of the second fragment to point to itself.  This causes
sctp_skb_pull() to potentially recurse indefinitely.

Proposed solution is to make a copy of the skb when attempting to link
things using frag_list.

Signed-off-by: Vladislav Yasevich 
Signed-off-by: Sridhar Samudrala 
Signed-off-by: David S. Miller 
Signed-off-by: Chris Wright