linux-toradex.git/include/net, branch v2.6.27.62

sctp: Fix oops when sending queued ASCONF chunks

2011-04-30T14:53:10+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 a race between ICMP protocol unreachable and connect()

2011-02-09T21:15:38+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 
Signed-off-by: Willy Tarreau

x25: Patch to fix bug 15678 - x25 accesses fields beyond end of packet.

2010-12-09T21:24:20+00:00

commit f5eb917b861828da18dc28854308068c66d1449a upstream.

Here is a patch to stop X.25 examining fields beyond the end of the packet.

For example, when a simple CALL ACCEPTED was received:

	10 10 0f

x25_parse_facilities was attempting to decode the FACILITIES field, but this
packet contains no facilities field.

Signed-off-by: John Hughes 
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:08:46+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

ipv6: reassembly: use seperate reassembly queues for conntrack and local delivery

2010-01-06T23:17:14+00:00

commit 0b5ccb2ee250136dd7385b1c7da28417d0d4d32d upstream.

Currently the same reassembly queue might be used for packets reassembled
by conntrack in different positions in the stack (PREROUTING/LOCAL_OUT),
as well as local delivery. This can cause "packet jumps" when the fragment
completing a reassembled packet is queued from a different position in the
stack than the previous ones.

Add a "user" identifier to the reassembly queue key to seperate the queues
of each caller, similar to what we do for IPv4.

Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

irda: Add irda_skb_cb qdisc related padding

2009-11-10T00:52:30+00:00

commit 69c30e1e7492192f882a3fc11888b320fde5206a upstream.

We need to pad irda_skb_cb in order to keep it safe accross dev_queue_xmit()
calls. This is some ugly and temporary hack triggered by recent qisc code
changes.
Even though it fixes bugzilla.kernel.org bug #11795, it will be replaced by a
proper fix before 2.6.29 is released.

Signed-off-by: Samuel Ortiz 
Signed-off-by: David S. Miller 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x25: Fix sleep from timer on socket destroy.

2009-07-30T23:06:13+00:00

[ Upstream commit 14ebaf81e13ce66bff275380b246796fd16cbfa1 ]

If socket destuction gets delayed to a timer, we try to
lock_sock() from that timer which won't work.

Use bh_lock_sock() in that case.

Signed-off-by: David S. Miller 
Tested-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

net: Kill skb_truesize_check(), it only catches false-positives.

2009-03-17T00:52:42+00:00

[ Upstream commit 92a0acce186cde8ead56c6915d9479773673ea1a ]

A long time ago we had bugs, primarily in TCP, where we would modify
skb->truesize (for TSO queue collapsing) in ways which would corrupt
the socket memory accounting.

skb_truesize_check() was added in order to try and catch this error
more systematically.

However this debugging check has morphed into a Frankenstein of sorts
and these days it does nothing other than catch false-positives.

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

sctp: Fix crc32c calculations on big-endian arhes.

2009-02-17T17:46:19+00:00

[ Upstream commit 9c5ff5f75d0d0a1c7928ecfae3f38418b51a88e3 ]

crc32c algorithm provides a byteswaped result.  On little-endian
arches, the result ends up in big-endian/network byte order.
On big-endinan arches, the result ends up in little-endian
order and needs to be byte swapped again.  Thus calling cpu_to_le32
gives the right output.

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

net: Fix soft lockups/OOM issues w/ unix garbage collector (CVE-2008-5300)

2008-12-05T18:55:25+00:00

commit 5f23b734963ec7eaa3ebcd9050da0c9b7d143dd3 upstream.

This is an implementation of David Miller's suggested fix in:
  https://bugzilla.redhat.com/show_bug.cgi?id=470201

It has been updated to use wait_event() instead of
wait_event_interruptible().

Paraphrasing the description from the above report, it makes sendmsg()
block while UNIX garbage collection is in progress. This avoids a
situation where child processes continue to queue new FDs over a
AF_UNIX socket to a parent which is in the exit path and running
garbage collection on these FDs. This contention can result in soft
lockups and oom-killing of unrelated processes.

Signed-off-by: dann frazier 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman