linux-stable.git/net/sctp/socket.c, branch linux-3.6.y

sctp: fix -ENOMEM result with invalid user space pointer in sendto() syscall

2012-12-17T17:27:20+00:00

[ Upstream commit 6e51fe7572590d8d86e93b547fab6693d305fd0d ]

Consider the following program, that sets the second argument to the
sendto() syscall incorrectly:

 #include 
 #include 
 #include 

 int main(void)
 {
         int fd;
         struct sockaddr_in sa;

         fd = socket(AF_INET, SOCK_STREAM, 132 /*IPPROTO_SCTP*/);
         if (fd < 0)
                 return 1;

         memset(&sa, 0, sizeof(sa));
         sa.sin_family = AF_INET;
         sa.sin_addr.s_addr = inet_addr("127.0.0.1");
         sa.sin_port = htons(11111);

         sendto(fd, NULL, 1, 0, (struct sockaddr *)&sa, sizeof(sa));

         return 0;
 }

We get -ENOMEM:

 $ strace -e sendto ./demo
 sendto(3, NULL, 1, 0, {sa_family=AF_INET, sin_port=htons(11111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ENOMEM (Cannot allocate memory)

Propagate the error code from sctp_user_addto_chunk(), so that we will
tell user space what actually went wrong:

 $ strace -e sendto ./demo
 sendto(3, NULL, 1, 0, {sa_family=AF_INET, sin_port=htons(11111), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EFAULT (Bad address)

Noticed while running Trinity (the syscall fuzzer).

Signed-off-by: Tommi Rantala 
Acked-by: Vlad Yasevich 
Acked-by: Neil Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sctp: Implement quick failover draft from tsvwg

2012-07-22T19:13:46+00:00

I've seen several attempts recently made to do quick failover of sctp transports
by reducing various retransmit timers and counters.  While its possible to
implement a faster failover on multihomed sctp associations, its not
particularly robust, in that it can lead to unneeded retransmits, as well as
false connection failures due to intermittent latency on a network.

Instead, lets implement the new ietf quick failover draft found here:
http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05

This will let the sctp stack identify transports that have had a small number of
errors, and avoid using them quickly until their reliability can be
re-established.  I've tested this out on two virt guests connected via multiple
isolated virt networks and believe its in compliance with the above draft and
works well.

Signed-off-by: Neil Horman 
CC: Vlad Yasevich 
CC: Sridhar Samudrala 
CC: "David S. Miller" 
CC: linux-sctp@vger.kernel.org
CC: joe@perches.com
Acked-by: Vlad Yasevich 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2012-07-19T18:17:30+00:00

Conflicts:
	drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c

sctp: Fix list corruption resulting from freeing an association on a list

2012-07-17T05:32:26+00:00

A few days ago Dave Jones reported this oops:

[22766.294255] general protection fault: 0000 [#1] PREEMPT SMP
[22766.295376] CPU 0
[22766.295384] Modules linked in:
[22766.387137]  ffffffffa169f292 6b6b6b6b6b6b6b6b ffff880147c03a90
ffff880147c03a74
[22766.387135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 00000000000
[22766.387136] Process trinity-watchdo (pid: 10896, threadinfo ffff88013e7d2000,
[22766.387137] Stack:
[22766.387140]  ffff880147c03a10
[22766.387140]  ffffffffa169f2b6
[22766.387140]  ffff88013ed95728
[22766.387143]  0000000000000002
[22766.387143]  0000000000000000
[22766.387143]  ffff880003fad062
[22766.387144]  ffff88013c120000
[22766.387144]
[22766.387145] Call Trace:
[22766.387145]  
[22766.387150]  [] ? __sctp_lookup_association+0x62/0xd0
[sctp]
[22766.387154]  [] __sctp_lookup_association+0x86/0xd0 [sctp]
[22766.387157]  [] sctp_rcv+0x207/0xbb0 [sctp]
[22766.387161]  [] ? trace_hardirqs_off_caller+0x28/0xd0
[22766.387163]  [] ? nf_hook_slow+0x133/0x210
[22766.387166]  [] ? ip_local_deliver_finish+0x4c/0x4c0
[22766.387168]  [] ip_local_deliver_finish+0x18d/0x4c0
[22766.387169]  [] ? ip_local_deliver_finish+0x4c/0x4c0
[22766.387171]  [] ip_local_deliver+0x47/0x80
[22766.387172]  [] ip_rcv_finish+0x150/0x680
[22766.387174]  [] ip_rcv+0x214/0x320
[22766.387176]  [] __netif_receive_skb+0x7b7/0x910
[22766.387178]  [] ? __netif_receive_skb+0x11c/0x910
[22766.387180]  [] ? put_lock_stats.isra.25+0xe/0x40
[22766.387182]  [] netif_receive_skb+0x23/0x1f0
[22766.387183]  [] ? dev_gro_receive+0x139/0x440
[22766.387185]  [] napi_skb_finish+0x70/0xa0
[22766.387187]  [] napi_gro_receive+0xf5/0x130
[22766.387218]  [] e1000_receive_skb+0x59/0x70 [e1000e]
[22766.387242]  [] e1000_clean_rx_irq+0x28b/0x460 [e1000e]
[22766.387266]  [] e1000e_poll+0x78/0x430 [e1000e]
[22766.387268]  [] net_rx_action+0x1aa/0x3d0
[22766.387270]  [] ? account_system_vtime+0x10f/0x130
[22766.387273]  [] __do_softirq+0xe0/0x420
[22766.387275]  [] call_softirq+0x1c/0x30
[22766.387278]  [] do_softirq+0xd5/0x110
[22766.387279]  [] irq_exit+0xd5/0xe0
[22766.387281]  [] do_IRQ+0x63/0xd0
[22766.387283]  [] common_interrupt+0x6f/0x6f
[22766.387283]  
[22766.387284]
[22766.387285]  [] ? retint_swapgs+0x13/0x1b
[22766.387285] Code: c0 90 5d c3 66 0f 1f 44 00 00 4c 89 c8 5d c3 0f 1f 00 55 48
89 e5 48 83
ec 20 48 89 5d e8 4c 89 65 f0 4c 89 6d f8 66 66 66 66 90 <0f> b7 87 98 00 00 00
48 89 fb
49 89 f5 66 c1 c0 08 66 39 46 02
[22766.387307]
[22766.387307] RIP
[22766.387311]  [] sctp_assoc_is_match+0x19/0x90 [sctp]
[22766.387311]  RSP 
[22766.387142]  ffffffffa16ab120
[22766.599537] ---[ end trace 3f6dae82e37b17f5 ]---
[22766.601221] Kernel panic - not syncing: Fatal exception in interrupt

It appears from his analysis and some staring at the code that this is likely
occuring because an association is getting freed while still on the
sctp_assoc_hashtable.  As a result, we get a gpf when traversing the hashtable
while a freed node corrupts part of the list.

Nominally I would think that an mibalanced refcount was responsible for this,
but I can't seem to find any obvious imbalance.  What I did note however was
that the two places where we create an association using
sctp_primitive_ASSOCIATE (__sctp_connect and sctp_sendmsg), have failure paths
which free a newly created association after calling sctp_primitive_ASSOCIATE.
sctp_primitive_ASSOCIATE brings us into the sctp_sf_do_prm_asoc path, which
issues a SCTP_CMD_NEW_ASOC side effect, which in turn adds a new association to
the aforementioned hash table.  the sctp command interpreter that process side
effects has not way to unwind previously processed commands, so freeing the
association from the __sctp_connect or sctp_sendmsg error path would lead to a
freed association remaining on this hash table.

I've fixed this but modifying sctp_[un]hash_established to use hlist_del_init,
which allows us to proerly use hlist_unhashed to check if the node is on a
hashlist safely during a delete.  That in turn alows us to safely call
sctp_unhash_established in the __sctp_connect and sctp_sendmsg error paths
before freeing them, regardles of what the associations state is on the hash
list.

I noted, while I was doing this, that the __sctp_unhash_endpoint was using
hlist_unhsashed in a simmilar fashion, but never nullified any removed nodes
pointers to make that function work properly, so I fixed that up in a simmilar
fashion.

I attempted to test this using a virtual guest running the SCTP_RR test from
netperf in a loop while running the trinity fuzzer, both in a loop.  I wasn't
able to recreate the problem prior to this fix, nor was I able to trigger the
failure after (neither of which I suppose is suprising).  Given the trace above
however, I think its likely that this is what we hit.

Signed-off-by: Neil Horman 
Reported-by: davej@redhat.com
CC: davej@redhat.com
CC: "David S. Miller" 
CC: Vlad Yasevich 
CC: Sridhar Samudrala 
CC: linux-sctp@vger.kernel.org
Signed-off-by: David S. Miller

sctp: Adjust PMTU updates to accomodate route invalidation.

2012-07-16T10:57:14+00:00

This adjusts the call to dst_ops->update_pmtu() so that we can
transparently handle the fact that, in the future, the dst itself can
be invalidated by the PMTU update (when we have non-host routes cached
in sockets).

Signed-off-by: David S. Miller

net: Convert net_ratelimit uses to net__ratelimited

2012-05-15T17:45:03+00:00

Standardize the net core ratelimited logging functions.

Coalesce formats, align arguments.
Change a printk then vprintk sequence to use printf extension %pV.

Signed-off-by: Joe Perches 
Signed-off-by: David S. Miller

sctp: Allow struct sctp_event_subscribe to grow without breaking binaries

2012-04-04T22:05:02+00:00

getsockopt(..., SCTP_EVENTS, ...) performs a length check and returns
an error if the user provides less bytes than the size of struct
sctp_event_subscribe.

Struct sctp_event_subscribe needs to be extended by an u8 for every
new event or notification type that is added.

This obviously makes getsockopt fail for binaries that are compiled
against an older versions of  which do not contain
all event types.

This patch changes getsockopt behaviour to no longer return an error
if not enough bytes are being provided by the user. Instead, it
returns as much of sctp_event_subscribe as fits into the provided buffer.

This leads to the new behavior that users see what they have been aware
of at compile time.

The setsockopt(..., SCTP_EVENTS, ...) API is already behaving like this.

Signed-off-by: Thomas Graf 
Acked-by: Vlad Yasevich 
Signed-off-by: David S. Miller

sctp: Export sctp_do_peeloff

2012-03-08T21:52:08+00:00

lookup sctp_association within sctp_do_peeloff() to enable its use outside of
the sctp code with minimal knowledge of the former.

Signed-off-by: Benjamin Poirier 
Acked-by: Vlad Yasevich 
Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2011-12-23T22:13:56+00:00

Conflicts:
	net/bluetooth/l2cap_core.c

Just two overlapping changes, one added an initialization of
a local variable, and another change added a new local variable.

Signed-off-by: David S. Miller

sctp: fix incorrect overflow check on autoclose

2011-12-19T21:25:46+00:00

Commit 8ffd3208 voids the previous patches f6778aab and 810c0719 for
limiting the autoclose value.  If userspace passes in -1 on 32-bit
platform, the overflow check didn't work and autoclose would be set
to 0xffffffff.

This patch defines a max_autoclose (in seconds) for limiting the value
and exposes it through sysctl, with the following intentions.

1) Avoid overflowing autoclose * HZ.

2) Keep the default autoclose bound consistent across 32- and 64-bit
   platforms (INT_MAX / HZ in this patch).

3) Keep the autoclose value consistent between setsockopt() and
   getsockopt() calls.

Suggested-by: Vlad Yasevich 
Signed-off-by: Xi Wang 
Signed-off-by: David S. Miller