linux-toradex.git/include, branch v2.6.27.48

vfs: add NOFOLLOW flag to umount(2)

2010-07-05T18:08:46+00:00

commit db1f05bb85d7966b9176e293f3ceead1cb8b5d79 upstream.

Add a new UMOUNT_NOFOLLOW flag to umount(2).  This is needed to prevent
symlink attacks in unprivileged unmounts (fuse, samba, ncpfs).

Additionally, return -EINVAL if an unknown flag is used (and specify
an explicitly unused flag: UMOUNT_UNUSED).  This makes it possible for
the caller to determine if a flag is supported or not.

CC: Eugene Teo 
CC: Michael Kerrisk 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Al Viro 
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

nfsd: fix vm overcommit crash fix #2

2010-05-26T21:27:09+00:00

commit 1b79cd04fab80be61dcd2732e2423aafde9a4c1c upstream.

The previous patch from Alan Cox ("nfsd: fix vm overcommit crash",
commit 731572d39fcd3498702eda4600db4c43d51e0b26) fixed the problem where
knfsd crashes on exported shmemfs objects and strict overcommit is set.

But the patch forgot supporting the case when CONFIG_SECURITY is
disabled.

This patch copies a part of his fix which is mainly for detecting a bug
earlier.

Acked-by: James Morris 
Signed-off-by: Alan Cox 
Signed-off-by: Junjiro R. Okajima 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

nfsd: fix vm overcommit crash

2010-05-26T21:27:09+00:00

commit 731572d39fcd3498702eda4600db4c43d51e0b26 upstream.

Junjiro R.  Okajima reported a problem where knfsd crashes if you are
using it to export shmemfs objects and run strict overcommit.  In this
situation the current->mm based modifier to the overcommit goes through a
NULL pointer.

We could simply check for NULL and skip the modifier but we've caught
other real bugs in the past from mm being NULL here - cases where we did
need a valid mm set up (eg the exec bug about a year ago).

To preserve the checks and get the logic we want shuffle the checking
around and add a new helper to the vm_ security wrappers

Also fix a current->mm reference in nommu that should use the passed mm

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix build]
Reported-by: Junjiro R. Okajima 
Acked-by: James Morris 
Signed-off-by: Alan Cox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

vfs: Remove the range_cont writeback mode.

2010-05-26T21:27:06+00:00

commit 74baaaaec8b4f22e1ae279f5ecca4ff705b28912 upstream.

Ext4 was the only user of range_cont writeback mode and ext4 switched
to a different method. So remove the range_cont mode which is not used
in the kernel.

Signed-off-by: Aneesh Kumar K.V 
Signed-off-by: "Theodore Ts'o" 
CC: linux-fsdevel@vger.kernel.org
Signed-off-by: Jayson R. King 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

percpu counter: clean up percpu_counter_sum_and_set()

2010-05-26T21:27:05+00:00

commit 1f7c14c62ce63805f9574664a6c6de3633d4a354 upstream.

percpu_counter_sum_and_set() and percpu_counter_sum() is the same except
the former updates the global counter after accounting.  Since we are
taking the fbc->lock to calculate the precise value of the counter in
percpu_counter_sum() anyway, it should simply set fbc->count too, as the
percpu_counter_sum_and_set() does.

This patch merges these two interfaces into one.

Signed-off-by: Mingming Cao 
Acked-by: Peter Zijlstra 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Jayson R. King 
Signed-off-by: Theodore Ts'o

KVM: VMX: Check cpl before emulating debug register access

2010-04-01T22:52:24+00:00

commit 0a79b009525b160081d75cef5dbf45817956acf2 upstream.

Debug registers may only be accessed from cpl 0.  Unfortunately, vmx will
code to emulate the instruction even though it was issued from guest
userspace, possibly leading to an unexpected trap later.

Signed-off-by: Avi Kivity 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Greg Kroah-Hartman

KVM: x86 emulator: limit instructions to 15 bytes

2010-04-01T22:52:23+00:00

commit eb3c79e64a70fb8f7473e30fa07e89c1ecc2c9bb upstream

[ : backport to 2.6.27 ]

While we are never normally passed an instruction that exceeds 15 bytes,
smp games can cause us to attempt to interpret one, which will cause
large latencies in non-preempt hosts.

Signed-off-by: Avi Kivity 
Signed-off-by: Greg Kroah-Hartman

sched: wakeup preempt when small overlap

2010-04-01T22:52:21+00:00

commit 15afe09bf496ae10c989e1a375a6b5da7bd3e16e upstream.

Lin Ming reported a 10% OLTP regression against 2.6.27-rc4.

The difference seems to come from different preemption agressiveness,
which affects the cache footprint of the workload and its effective
cache trashing.

Aggresively preempt a task if its avg overlap is very small, this should
avoid the task going to sleep and find it still running when we schedule
back to it - saving a wakeup.

Reported-by: Lin Ming 
Signed-off-by: Peter Zijlstra 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

sched: fine-tune SD_SIBLING_INIT

2010-04-01T22:52:20+00:00

commit 52c642f33b14bfa1b00ef2b68296effb34a573f3 upstream.

fine-tune the HT sched-domains parameters as well.

On a HT capable box, this increases lat_ctx performance from 23.87
usecs to 1.49 usecs:

 # before

 $ ./lat_ctx -s 0 2

   "size=0k ovr=1.89
    2 23.87

 # after

 $ ./lat_ctx -s 0 2

   "size=0k ovr=1.84
     2 1.49

Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman