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

sctp: fix to calc the INIT/INIT-ACK chunk length correctly is set

2011-04-14T23:53:44+00:00

commit a8170c35e738d62e9919ce5b109cf4ed66e95bde upstream.

When calculating the INIT/INIT-ACK chunk length, we should not
only account the length of parameters, but also the parameters
zero padding length, such as AUTH HMACS parameter and CHUNKS
parameter. Without the parameters zero padding length we may get
following oops.

skb_over_panic: text:ce2068d2 len:130 put:6 head:cac3fe00 data:cac3fe00 tail:0xcac3fe82 end:0xcac3fe80 dev:
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:127!
invalid opcode: 0000 [#2] SMP
last sysfs file: /sys/module/aes_generic/initstate
Modules linked in: authenc ......

Pid: 4102, comm: sctp_darn Tainted: G      D    2.6.34-rc2 #6
EIP: 0060:[] EFLAGS: 00010282 CPU: 0
EIP is at skb_over_panic+0x37/0x3e
EAX: 00000078 EBX: c07c024b ECX: c07c02b9 EDX: cb607b78
ESI: 00000000 EDI: cac3fe7a EBP: 00000002 ESP: cb607b74
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process sctp_darn (pid: 4102, ti=cb607000 task=cabdc990 task.ti=cb607000)
Stack:
 c07c02b9 ce2068d2 00000082 00000006 cac3fe00 cac3fe00 cac3fe82 cac3fe80
<0> c07c024b cac3fe7c cac3fe7a c0608dec ca986e80 ce2068d2 00000006 0000007a
<0> cb8120ca ca986e80 cb812000 00000003 cb8120c4 ce208a25 cb8120ca cadd9400
Call Trace:
 [] ? sctp_addto_chunk+0x45/0x85 [sctp]
 [] ? skb_put+0x2e/0x32
 [] ? sctp_addto_chunk+0x45/0x85 [sctp]
 [] ? sctp_make_init+0x279/0x28c [sctp]
 [] ? apic_timer_interrupt+0x2a/0x30
 [] ? sctp_sf_do_prm_asoc+0x2b/0x7b [sctp]
 [] ? sctp_do_sm+0xa0/0x14a [sctp]
 [] ? sctp_pname+0x0/0x14 [sctp]
 [] ? sctp_primitive_ASSOCIATE+0x2b/0x31 [sctp]
 [] ? sctp_sendmsg+0x7a0/0x9eb [sctp]
 [] ? inet_sendmsg+0x3b/0x43
 [] ? task_tick_fair+0x2d/0xd9
 [] ? sock_sendmsg+0xa7/0xc1
 [] ? smp_apic_timer_interrupt+0x6b/0x75
 [] ? dequeue_task_fair+0x34/0x19b
 [] ? sched_clock_local+0x17/0x11e
 [] ? _copy_from_user+0x2b/0x10c
 [] ? verify_iovec+0x3c/0x6a
 [] ? sys_sendmsg+0x186/0x1e2
 [] ? __wake_up_common+0x34/0x5b
 [] ? __wake_up+0x2c/0x3b
 [] ? tty_wakeup+0x43/0x47
 [] ? remove_wait_queue+0x16/0x24
 [] ? n_tty_read+0x5b8/0x65e
 [] ? default_wake_function+0x0/0x8
 [] ? sys_socketcall+0x17f/0x1cd
 [] ? sysenter_do_call+0x12/0x22
Code: 0f 45 de 53 ff b0 98 00 00 00 ff b0 94 ......
EIP: [] skb_over_panic+0x37/0x3e SS:ESP 0068:cb607b74

To reproduce:

# modprobe sctp
# echo 1 > /proc/sys/net/sctp/addip_enable
# echo 1 > /proc/sys/net/sctp/auth_enable
# sctp_test -H 3ffe:501:ffff:100:20c:29ff:fe4d:f37e -P 800 -l
# sctp_darn -H 3ffe:501:ffff:100:20c:29ff:fe4d:f37e -P 900 -h 192.168.0.21 -p 800 -I -s -t
sctp_darn ready to send...
3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> bindx-add=192.168.0.21
3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> bindx-add=192.168.1.21
3ffe:501:ffff:100:20c:29ff:fe4d:f37e:900-192.168.0.21:800 Interactive mode> snd=10

------------------------------------------------------------------
eth0 has addresses: 3ffe:501:ffff:100:20c:29ff:fe4d:f37e and 192.168.0.21
eth1 has addresses: 192.168.1.21
------------------------------------------------------------------

Reported-by: George Cheimonidis 
Signed-off-by: Wei Yongjun 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sctp: Fix oops when sending queued ASCONF chunks

2011-03-07T23:17:55+00:00

commit c0786693404cffd80ca3cb6e75ee7b35186b2825 upstream.

When we finish processing ASCONF_ACK chunk, we try to send
the next queued ASCONF.  This action runs the sctp state
machine recursively and it's not prepared to do so.

kernel BUG at kernel/timer.c:790!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/module/ipv6/initstate
Modules linked in: sha256_generic sctp libcrc32c ipv6 dm_multipath
uinput 8139too i2c_piix4 8139cp mii i2c_core pcspkr virtio_net joydev
floppy virtio_blk virtio_pci [last unloaded: scsi_wait_scan]

Pid: 0, comm: swapper Not tainted 2.6.34-rc4 #15 /Bochs
EIP: 0060:[] EFLAGS: 00010286 CPU: 0
EIP is at add_timer+0xd/0x1b
EAX: cecbab14 EBX: 000000f0 ECX: c0957b1c EDX: 03595cf4
ESI: cecba800 EDI: cf276f00 EBP: c0957aa0 ESP: c0957aa0
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process swapper (pid: 0, ti=c0956000 task=c0988ba0 task.ti=c0956000)
Stack:
 c0957ae0 d1851214 c0ab62e4 c0ab5f26 0500ffff 00000004 00000005 00000004
<0> 00000000 d18694fd 00000004 1666b892 cecba800 cecba800 c0957b14
00000004
<0> c0957b94 d1851b11 ceda8b00 cecba800 cf276f00 00000001 c0957b14
000000d0
Call Trace:
 [] ? sctp_side_effects+0x607/0xdfc [sctp]
 [] ? sctp_do_sm+0x108/0x159 [sctp]
 [] ? sctp_pname+0x0/0x1d [sctp]
 [] ? sctp_primitive_ASCONF+0x36/0x3b [sctp]
 [] ? sctp_process_asconf_ack+0x2a4/0x2d3 [sctp]
 [] ? sctp_sf_do_asconf_ack+0x1dd/0x2b4 [sctp]
 [] ? sctp_do_sm+0xb8/0x159 [sctp]
 [] ? sctp_cname+0x0/0x52 [sctp]
 [] ? sctp_assoc_bh_rcv+0xac/0xe1 [sctp]
 [] ? sctp_inq_push+0x2d/0x30 [sctp]
 [] ? sctp_rcv+0x797/0x82e [sctp]

Tested-by: Wei Yongjun 
Signed-off-by: Yuansong Qiao 
Signed-off-by: Shuaijun Zhang 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Cc: maximilian attems 
Signed-off-by: Greg Kroah-Hartman

sctp: Fix out-of-bounds reading in sctp_asoc_get_hmac()

2011-03-02T14:46:33+00:00

commit 51e97a12bef19b7e43199fc153cf9bd5f2140362 upstream.

The sctp_asoc_get_hmac() function iterates through a peer's hmac_ids
array and attempts to ensure that only a supported hmac entry is
returned.  The current code fails to do this properly - if the last id
in the array is out of range (greater than SCTP_AUTH_HMAC_ID_MAX), the
id integer remains set after exiting the loop, and the address of an
out-of-bounds entry will be returned and subsequently used in the parent
function, causing potentially ugly memory corruption.  This patch resets
the id integer to 0 on encountering an invalid id so that NULL will be
returned after finishing the loop if no valid ids are found.

Signed-off-by: Dan Rosenberg 
Acked-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sctp: Fix a race between ICMP protocol unreachable and connect()

2011-01-07T22:43:18+00:00

commit 50b5d6ad63821cea324a5a7a19854d4de1a0a819 upstream.

ICMP protocol unreachable handling completely disregarded
the fact that the user may have locked the socket.  It proceeded
to destroy the association, even though the user may have
held the lock and had a ref on the association.  This resulted
in the following:

Attempt to release alive inet socket f6afcc00

=========================
[ BUG: held lock freed! ]
-------------------------
somenu/2672 is freeing memory f6afcc00-f6afcfff, with a lock still held
there!
 (sk_lock-AF_INET){+.+.+.}, at: [] sctp_connect+0x13/0x4c
1 lock held by somenu/2672:
 #0:  (sk_lock-AF_INET){+.+.+.}, at: [] sctp_connect+0x13/0x4c

stack backtrace:
Pid: 2672, comm: somenu Not tainted 2.6.32-telco #55
Call Trace:
 [] ? printk+0xf/0x11
 [] debug_check_no_locks_freed+0xce/0xff
 [] kmem_cache_free+0x21/0x66
 [] __sk_free+0x9d/0xab
 [] sk_free+0x1c/0x1e
 [] sctp_association_put+0x32/0x89
 [] __sctp_connect+0x36d/0x3f4
 [] ? sctp_connect+0x13/0x4c
 [] ? autoremove_wake_function+0x0/0x33
 [] sctp_connect+0x31/0x4c
 [] inet_dgram_connect+0x4b/0x55
 [] sys_connect+0x54/0x71
 [] ? lock_release_non_nested+0x88/0x239
 [] ? might_fault+0x42/0x7c
 [] ? might_fault+0x42/0x7c
 [] sys_socketcall+0x6d/0x178
 [] ? trace_hardirqs_on_thunk+0xc/0x10
 [] syscall_call+0x7/0xb

This was because the sctp_wait_for_connect() would aqcure the socket
lock and then proceed to release the last reference count on the
association, thus cause the fully destruction path to finish freeing
the socket.

The simplest solution is to start a very short timer in case the socket
is owned by user.  When the timer expires, we can do some verification
and be able to do the release properly.

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Limit sysctl_tcp_mem and sysctl_udp_mem initializers to prevent integer overflows.

2010-12-09T21:27:06+00:00

[ Upstream fixed this in a different way as parts of the commits:
	8d987e5c7510 (net: avoid limits overflow)
	a9febbb4bd13 (sysctl: min/max bounds are optional)
	27b3d80a7b6a (sysctl: fix min/max handling in __do_proc_doulongvec_minmax())
 -DaveM ]

On a 16TB x86_64 machine, sysctl_tcp_mem[2], sysctl_udp_mem[2], and
sysctl_sctp_mem[2] can integer overflow.  Set limit such that they are
maximized without overflowing.

Signed-off-by: Robin Holt 
To: "David S. Miller" 
Cc: Willy Tarreau 
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-sctp@vger.kernel.org
Cc: Alexey Kuznetsov 
Cc: "Pekka Savola (ipv6)" 
Cc: James Morris 
Cc: Hideaki YOSHIFUJI 
Cc: Patrick McHardy 
Cc: Vlad Yasevich 
Cc: Sridhar Samudrala 
Signed-off-by: Greg Kroah-Hartman

sctp: Do not reset the packet during sctp_packet_config().

2010-09-27T00:21:35+00:00

commit 4bdab43323b459900578b200a4b8cf9713ac8fab upstream.

sctp_packet_config() is called when getting the packet ready
for appending of chunks.  The function should not touch the
current state, since it's possible to ping-pong between two
transports when sending, and that can result packet corruption
followed by skb overlfow crash.

Reported-by: Thomas Dreibholz 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sctp: fix append error cause to ERROR chunk correctly

2010-07-05T18:11:21+00:00

commit 2e3219b5c8a2e44e0b83ae6e04f52f20a82ac0f2 upstream.

commit 5fa782c2f5ef6c2e4f04d3e228412c9b4a4c8809
  sctp: Fix skb_over_panic resulting from multiple invalid \
    parameter errors (CVE-2010-1173) (v4)

cause 'error cause' never be add the the ERROR chunk due to
some typo when check valid length in sctp_init_cause_fixed().

Signed-off-by: Wei Yongjun 
Reviewed-by: Neil Horman 
Acked-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sctp: Fix skb_over_panic resulting from multiple invalid parameter errors (CVE-2010-1173) (v4)

2010-07-05T18:11:14+00:00

commit 5fa782c2f5ef6c2e4f04d3e228412c9b4a4c8809 upstream.

Ok, version 4

Change Notes:
1) Minor cleanups, from Vlads notes

Summary:

Hey-
	Recently, it was reported to me that the kernel could oops in the
following way:

<5> kernel BUG at net/core/skbuff.c:91!
<5> invalid operand: 0000 [#1]
<5> Modules linked in: sctp netconsole nls_utf8 autofs4 sunrpc iptable_filter
ip_tables cpufreq_powersave parport_pc lp parport vmblock(U) vsock(U) vmci(U)
vmxnet(U) vmmemctl(U) vmhgfs(U) acpiphp dm_mirror dm_mod button battery ac md5
ipv6 uhci_hcd ehci_hcd snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss
snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_ac97_codec snd soundcore
pcnet32 mii floppy ext3 jbd ata_piix libata mptscsih mptsas mptspi mptscsi
mptbase sd_mod scsi_mod
<5> CPU:    0
<5> EIP:    0060:[]    Not tainted VLI
<5> EFLAGS: 00010216   (2.6.9-89.0.25.EL)
<5> EIP is at skb_over_panic+0x1f/0x2d
<5> eax: 0000002c   ebx: c033f461   ecx: c0357d96   edx: c040fd44
<5> esi: c033f461   edi: df653280   ebp: 00000000   esp: c040fd40
<5> ds: 007b   es: 007b   ss: 0068
<5> Process swapper (pid: 0, threadinfo=c040f000 task=c0370be0)
<5> Stack: c0357d96 e0c29478 00000084 00000004 c033f461 df653280 d7883180
e0c2947d
<5>        00000000 00000080 df653490 00000004 de4f1ac0 de4f1ac0 00000004
df653490
<5>        00000001 e0c2877a 08000800 de4f1ac0 df653490 00000000 e0c29d2e
00000004
<5> Call Trace:
<5>  [] sctp_addto_chunk+0xb0/0x128 [sctp]
<5>  [] sctp_addto_chunk+0xb5/0x128 [sctp]
<5>  [] sctp_init_cause+0x3f/0x47 [sctp]
<5>  [] sctp_process_unk_param+0xac/0xb8 [sctp]
<5>  [] sctp_verify_init+0xcc/0x134 [sctp]
<5>  [] sctp_sf_do_5_1B_init+0x83/0x28e [sctp]
<5>  [] sctp_do_sm+0x41/0x77 [sctp]
<5>  [] cache_grow+0x140/0x233
<5>  [] sctp_endpoint_bh_rcv+0xc5/0x108 [sctp]
<5>  [] sctp_inq_push+0xe/0x10 [sctp]
<5>  [] sctp_rcv+0x454/0x509 [sctp]
<5>  [] ipt_hook+0x17/0x1c [iptable_filter]
<5>  [] nf_iterate+0x40/0x81
<5>  [] ip_local_deliver_finish+0x0/0x151
<5>  [] ip_local_deliver_finish+0xc6/0x151
<5>  [] nf_hook_slow+0x83/0xb5
<5>  [] ip_local_deliver+0x1a2/0x1a9
<5>  [] ip_local_deliver_finish+0x0/0x151
<5>  [] ip_rcv+0x334/0x3b4
<5>  [] netif_receive_skb+0x320/0x35b
<5>  [] init_stall_timer+0x67/0x6a [uhci_hcd]
<5>  [] process_backlog+0x6c/0xd9
<5>  [] net_rx_action+0xfe/0x1f8
<5>  [] __do_softirq+0x35/0x79
<5>  [] handle_IRQ_event+0x0/0x4f
<5>  [] do_softirq+0x46/0x4d

Its an skb_over_panic BUG halt that results from processing an init chunk in
which too many of its variable length parameters are in some way malformed.

The problem is in sctp_process_unk_param:
if (NULL == *errp)
	*errp = sctp_make_op_error_space(asoc, chunk,
					 ntohs(chunk->chunk_hdr->length));

	if (*errp) {
		sctp_init_cause(*errp, SCTP_ERROR_UNKNOWN_PARAM,
				 WORD_ROUND(ntohs(param.p->length)));
		sctp_addto_chunk(*errp,
			WORD_ROUND(ntohs(param.p->length)),
				  param.v);

When we allocate an error chunk, we assume that the worst case scenario requires
that we have chunk_hdr->length data allocated, which would be correct nominally,
given that we call sctp_addto_chunk for the violating parameter.  Unfortunately,
we also, in sctp_init_cause insert a sctp_errhdr_t structure into the error
chunk, so the worst case situation in which all parameters are in violation
requires chunk_hdr->length+(sizeof(sctp_errhdr_t)*param_count) bytes of data.

The result of this error is that a deliberately malformed packet sent to a
listening host can cause a remote DOS, described in CVE-2010-1173:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-1173

I've tested the below fix and confirmed that it fixes the issue.  We move to a
strategy whereby we allocate a fixed size error chunk and ignore errors we don't
have space to report.  Tested by me successfully

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

sctp: on T3_RTX retransmit all the in-flight chunks

2009-11-29T08:14:02+00:00

When retransmitting due to T3 timeout, retransmit all the
in-flight chunks for the corresponding  transport/path, including
chunks sent less then 1 rto ago.
This is the correct behaviour according to rfc4960 section 6.3.3
E3 and
"Note: Any DATA chunks that were sent to the address for which the
 T3-rtx timer expired but did not fit in one MTU (rule E3 above)
 should be marked for retransmission and sent as soon as cwnd
 allows (normally, when a SACK arrives). ".

This fixes problems when more then one path is present and the T3
retransmission of the first chunk that timeouts stops the T3 timer
for the initial active path, leaving all the other in-flight
chunks waiting forever or until a new chunk is transmitted on the
same path and timeouts (and this will happen only if the cwnd
allows sending new chunks, but since cwnd was dropped to MTU by
the timeout => it will wait until the first heartbeat).

Example: 10 packets in flight, sent at 0.1 s intervals on the
primary path. The primary path is down and the first packet
timeouts. The first packet is retransmitted on another path, the
T3 timer for the primary path is stopped and cwnd is set to MTU.
All the other 9 in-flight packets will not be retransmitted
(unless more new packets are sent on the primary path which depend
on cwnd allowing it, and even in this case the 9 packets will be
retransmitted only after a new packet timeouts which even in the
best case would be more then RTO).

This commit reverts d0ce92910bc04e107b2f3f2048f07e94f570035d and
also removes the now unused transport->last_rto, introduced in
 b6157d8e03e1e780660a328f7183bcbfa4a93a19.

p.s  The problem is not only when multiple paths are there.  It
can happen in a single homed environment.  If the application
stops sending data, it possible to have a hung association.

Signed-off-by: Andrei Pelinescu-Onciul 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller

sctp: Set socket source address when additing first transport

2009-11-14T03:56:52+00:00

Recent commits
	sctp: Get rid of an extra routing lookup when adding a transport
and
	sctp: Set source addresses on the association before adding transports

changed when routes are added to the sctp transports.  As such,
we didn't set the socket source address correctly when adding the first
transport.  The first transport is always the primary/active one, so
when adding it, set the socket source address.  This was causing
regression failures in SCTP tests.

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