linux.git/net/sctp, branch v2.6.25

[SCTP]: IPv4 vs IPv6 addresses mess in sctp_inet[6]addr_event.

2008-04-13T01:40:38+00:00

All IP addresses that are present in a system are duplicated on
struct sctp_sockaddr_entry. They are linked in the global list
called sctp_local_addr_list. And this struct unions IPv4 and IPv6
addresses.

So, there can be rare case, when a sockaddr_in.sin_addr coincides
with the corresponding part of the sockaddr_in6 and the notifier
for IPv4 will carry away an IPv6 entry.

The fix is to check the family before comparing the addresses.

Signed-off-by: Pavel Emelyanov 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller

[SCTP]: Fix compiler warning about const qualifiers

2008-04-13T01:40:06+00:00

Fix 3 warnings about discarding const qualifiers:

net/sctp/ulpevent.c:862: warning: passing argument 1 of 'sctp_event2skb' discards qualifiers from pointer target type
net/sctp/sm_statefuns.c:4393: warning: passing argument 1 of 'SCTP_ASOC' discards qualifiers from pointer target type
net/sctp/socket.c:5874: warning: passing argument 1 of 'cmsg_nxthdr' discards qualifiers from pointer target type

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller

[SCTP]: Fix protocol violation when receiving an error lenght INIT-ACK

2008-04-13T01:39:34+00:00

When receiving an error length INIT-ACK during COOKIE-WAIT,
a 0-vtag ABORT will be responsed. This action violates the
protocol apparently. This patch achieves the following things.
1 If the INIT-ACK contains all the fixed parameters, use init-tag
  recorded from INIT-ACK as vtag.
2 If the INIT-ACK doesn't contain all the fixed parameters,
  just reflect its vtag.

Signed-off-by: Gui Jianfeng 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller

[SCTP]: Add check for hmac_algo parameter in sctp_verify_param()

2008-04-13T01:39:19+00:00

RFC 4890 has the following text:

  The HMAC algorithm based on SHA-1 MUST be supported and
  included in the HMAC-ALGO parameter.

As a result, we need to check in sctp_verify_param() that HMAC_SHA1 is
present in the list.  If not, we should probably treat this as a
protocol violation.

It should also be a protocol violation if the HMAC parameter is empty.

Signed-off-by: Wei Yongjun 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller

[SCTP]: Fix a race between module load and protosw access

2008-03-20T22:17:14+00:00

There is a race is SCTP between the loading of the module
and the access by the socket layer to the protocol functions.
In particular, a list of addresss that SCTP maintains is
not initialized prior to the registration with the protosw.
Thus it is possible for a user application to gain access
to SCTP functions before everything has been initialized.
The problem shows up as odd crashes during connection
initializtion when we try to access the SCTP address list.

The solution is to refactor how we do registration and
initialize the lists prior to registering with the protosw.
Care must be taken since the address list initialization
depends on some other pieces of SCTP initialization.  Also
the clean-up in case of failure now also needs to be refactored.

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

[SCTP]: fix misannotated __sctp_rcv_asconf_lookup()

2008-03-18T05:47:32+00:00

Signed-off-by: Al Viro 
Signed-off-by: David S. Miller

[NET] endianness noise: INADDR_ANY

2008-03-18T05:44:53+00:00

Signed-off-by: Al Viro 
Signed-off-by: David S. Miller

[SCTP]: Fix local_addr deletions during list traversals.

2008-03-12T01:05:02+00:00

Since the lists are circular, we need to explicitely tag
the address to be deleted since we might end up freeing
the list head instead.  This fixes some interesting SCTP
crashes.

Signed-off-by: Chidambar 'ilLogict' Zinnoury 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller

[SCTP]: Bring MAX_BURST socket option into ietf API extension compliance

2008-03-05T21:44:46+00:00

Brings max_burst socket option set/get into line with the latest ietf
socket extensions api draft, while maintaining backwards
compatibility.

Signed-off-by: Neil Horman 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller

SCTP: Fix chunk parameter processing bug

2008-03-05T21:43:32+00:00

If an address family is not listed in "Supported Address Types"
parameter(INIT Chunk), but the packet is sent by that family, this
address family should be considered as supported by peer.  Otherwise,
an error condition will occur. For instance, if kernel receives an
IPV6 SCTP INIT chunk with "Support Address Types" parameter which
indicates just supporting IPV4 Address family. Kernel will reply an
IPV6 SCTP INIT ACK packet, but the source ipv6 address in ipv6 header
will be vacant. This is not correct.

refer to RFC4460 as following:
      IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported
      Address Types' parameter either IPv4 or IPv6, but uses the other
      family for sending the packet containing the INIT chunk, or if it
      also lists addresses of the other family in the INIT chunk, then
      the address family that is not listed in the 'Supported Address
      Types' parameter SHOULD also be considered as supported by the
      receiver of the INIT chunk.  The receiver of the INIT chunk SHOULD
      NOT respond with any kind of error indication.

Here is a fix to comply to RFC.

Signed-off-by: Gui Jianfeng 
Acked-by: Vlad Yasevich 
Signed-off-by: David S. Miller