linux-stable.git/kernel, branch linux-2.6.22.y

vm audit: add VM_DONTEXPAND to mmap for drivers that need it (CVE-2008-0007)

2008-02-06T19:43:46+00:00

Drivers that register a ->fault handler, but do not range-check the
offset argument, must set VM_DONTEXPAND in the vm_flags in order to
prevent an expanding mremap from overflowing the resource.

I've audited the tree and attempted to fix these problems (usually by
adding VM_DONTEXPAND where it is not obvious).

Signed-off-by: Nick Piggin 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Revert "Fix SMP poweroff hangs"

2007-12-14T18:32:00+00:00

This reverts the following changeset in 2.6.22.10 that caused a lot of
reported problems.

	From: Mark Lord 

	commit 4047727e5ae33f9b8d2b7766d1994ea6e5ec2991 from upstream

	We need to disable all CPUs other than the boot CPU (usually 0) before
	attempting to power-off modern SMP machines.  This fixes the
	hang-on-poweroff issue on my MythTV SMP box, and also on Thomas Gleixner's
	new toybox.

	Signed-off-by: Mark Lord 
	Acked-by: Thomas Gleixner 
	Cc: "Rafael J. Wysocki" 
	Signed-off-by: Andrew Morton 
	Signed-off-by: Linus Torvalds 
	Signed-off-by: Greg Kroah-Hartman 

There still is a remaining shutdown problem in 2.6.22 with old APM based
systems, but this fix is not the correct one

Signed-off-by: Greg Kroah-Hartman

futex: fix for futex_wait signal stack corruption

2007-12-14T18:31:56+00:00

From Steven Rostedt 

patch ce6bd420f43b28038a2c6e8fbb86ad24014727b6 in mainline.

David Holmes found a bug in the -rt tree with respect to
pthread_cond_timedwait. After trying his test program on the latest git
from mainline, I found the bug was there too.  The bug he was seeing
that his test program showed, was that if one were to do a "Ctrl-Z" on a
process that was in the pthread_cond_timedwait, and then did a "bg" on
that process, it would return with a "-ETIMEDOUT" but early. That is,
the timer would go off early.

Looking into this, I found the source of the problem. And it is a rather
nasty bug at that.

Here's the relevant code from kernel/futex.c: (not in order in the file)

[...]
smlinkage long sys_futex(u32 __user *uaddr, int op, u32 val,
                          struct timespec __user *utime, u32 __user *uaddr2,
                          u32 val3)
{
        struct timespec ts;
        ktime_t t, *tp = NULL;
        u32 val2 = 0;
        int cmd = op & FUTEX_CMD_MASK;

        if (utime && (cmd == FUTEX_WAIT || cmd == FUTEX_LOCK_PI)) {
                if (copy_from_user(&ts, utime, sizeof(ts)) != 0)
                        return -EFAULT;
                if (!timespec_valid(&ts))
                        return -EINVAL;

                t = timespec_to_ktime(ts);
                if (cmd == FUTEX_WAIT)
                        t = ktime_add(ktime_get(), t);
                tp = &t;
        }
[...]
        return do_futex(uaddr, op, val, tp, uaddr2, val2, val3);
}

[...]

long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout,
                u32 __user *uaddr2, u32 val2, u32 val3)
{
        int ret;
        int cmd = op & FUTEX_CMD_MASK;
        struct rw_semaphore *fshared = NULL;

        if (!(op & FUTEX_PRIVATE_FLAG))
                fshared = ¤t->mm->mmap_sem;

        switch (cmd) {
        case FUTEX_WAIT:
                ret = futex_wait(uaddr, fshared, val, timeout);

[...]

static int futex_wait(u32 __user *uaddr, struct rw_semaphore *fshared,
                      u32 val, ktime_t *abs_time)
{
[...]
               struct restart_block *restart;
                restart = ¤t_thread_info()->restart_block;
                restart->fn = futex_wait_restart;
                restart->arg0 = (unsigned long)uaddr;
                restart->arg1 = (unsigned long)val;
                restart->arg2 = (unsigned long)abs_time;
                restart->arg3 = 0;
                if (fshared)
                        restart->arg3 |= ARG3_SHARED;
                return -ERESTART_RESTARTBLOCK;
[...]

static long futex_wait_restart(struct restart_block *restart)
{
        u32 __user *uaddr = (u32 __user *)restart->arg0;
        u32 val = (u32)restart->arg1;
        ktime_t *abs_time = (ktime_t *)restart->arg2;
        struct rw_semaphore *fshared = NULL;

        restart->fn = do_no_restart_syscall;
        if (restart->arg3 & ARG3_SHARED)
                fshared = ¤t->mm->mmap_sem;
        return (long)futex_wait(uaddr, fshared, val, abs_time);
}

So when the futex_wait is interrupt by a signal we break out of the
hrtimer code and set up or return from signal. This code does not return
back to userspace, so we set up a RESTARTBLOCK.  The bug here is that we
save the "abs_time" which is a pointer to the stack variable "ktime_t t"
from sys_futex.

This returns and unwinds the stack before we get to call our signal. On
return from the signal we go to futex_wait_restart, where we update all
the parameters for futex_wait and call it. But here we have a problem
where abs_time is no longer valid.

I verified this with print statements, and sure enough, what abs_time
was set to ends up being garbage when we get to futex_wait_restart.

The solution I did to solve this (with input from Linus Torvalds)
was to add unions to the restart_block to allow system calls to
use the restart with specific parameters.  This way the futex code now
saves the time in a 64bit value in the restart block instead of storing
it on the stack.

Note: I'm a bit nervious to add "linux/types.h" and use u32 and u64
in thread_info.h, when there's a #ifdef __KERNEL__ just below that.
Not sure what that is there for.  If this turns out to be a problem, I've
tested this with using "unsigned int" for u32 and "unsigned long long" for
u64 and it worked just the same. I'm using u32 and u64 just to be
consistent with what the futex code uses.

Signed-off-by: Steven Rostedt 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Acked-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

hrtimers: avoid overflow for large relative timeouts (CVE-2007-5966)

2007-12-14T18:31:56+00:00

patch 62f0f61e6673e67151a7c8c0f9a09c7ea43fe2b5 in mainline

Relative hrtimers with a large timeout value might end up as negative
timer values, when the current time is added in hrtimer_start().

This in turn is causing the clockevents_set_next() function to set an
huge timeout and sleep for quite a long time when we have a clock
source which is capable of long sleeps like HPET. With PIT this almost
goes unnoticed as the maximum delta is ~27ms. The non-hrt/nohz code
sorts this out in the next timer interrupt, so we never noticed that
problem which has been there since the first day of hrtimers.

This bug became more apparent in 2.6.24 which activates HPET on more
hardware.

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

wait_task_stopped(): pass correct exit_code to wait_noreap_copyout()

2007-12-14T18:31:55+00:00

patch e6ceb32aa25fc33f21af84cc7a32fe289b3e860c in mainline.

In wait_task_stopped() exit_code already contains the right value for the
si_status member of siginfo, and this is simply set in the non WNOWAIT
case.

If you call waitid() with a stopped or traced process, you'll get the signal
in siginfo.si_status as expected -- however if you call waitid(WNOWAIT) at the
same time, you'll get the signal << 8 | 0x7f

Pass it unchanged to wait_noreap_copyout(); we would only need to shift it
and add 0x7f if we were returning it in the user status field and that
isn't used for any function that permits WNOWAIT.

Signed-off-by: Scott James Remnant 
Signed-off-by: Oleg Nesterov 
Cc: Roland McGrath 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

fix param_sysfs_builtin name length check

2007-11-21T17:25:53+00:00

patch 22800a2830ec07e7cc5c837999890ac47cc7f5de in mainline.

Commit faf8c714f4508207a9c81cc94dafc76ed6680b44 caused a regression:
parameter names longer than MAX_KBUILD_MODNAME will now be rejected,
although we just need to keep the module name part that short.  This patch
restores the old behaviour while still avoiding that memchr is called with
its length parameter larger than the total string length.

Signed-off-by: Jan Kiszka 
Cc: Dave Young 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

Fix compat futex hangs.

2007-11-21T17:25:52+00:00

[FUTEX]: Fix address computation in compat code.

[ Upstream commit: 3c5fd9c77d609b51c0bab682c9d40cbb496ec6f1 ]

compat_exit_robust_list() computes a pointer to the
futex entry in userspace as follows:

	(void __user *)entry + futex_offset

'entry' is a 'struct robust_list __user *', and
'futex_offset' is a 'compat_long_t' (typically a 's32').

Things explode if the 32-bit sign bit is set in futex_offset.

Type promotion sign extends futex_offset to a 64-bit value before
adding it to 'entry'.

This triggered a problem on sparc64 running 32-bit applications which
would lock up a cpu looping forever in the fault handling for the
userspace load in handle_futex_death().

Compat userspace runs with address masking (wherein the cpu zeros out
the top 32-bits of every effective address given to a memory operation
instruction) so the sparc64 fault handler accounts for this by
zero'ing out the top 32-bits of the fault address too.

Since the kernel properly uses the compat_uptr interfaces, kernel side
accesses to compat userspace work too since they will only use
addresses with the top 32-bit clear.

Because of this compat futex layer bug we get into the following loop
when executing the get_user() load near the top of handle_futex_death():

1) load from address '0xfffffffff7f16bd8', FAULT
2) fault handler clears upper 32-bits, processes fault
   for address '0xf7f16bd8' which succeeds
3) goto #1

I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto
for their tireless efforts helping me track down this bug.

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

wait_task_stopped: Check p->exit_state instead of TASK_TRACED (CVE-2007-5500)

2007-11-16T18:26:41+00:00

patch a3474224e6a01924be40a8255636ea5522c1023a in mainline

The original meaning of the old test (p->state > TASK_STOPPED) was
"not dead", since it was before TASK_TRACED existed and before the
state/exit_state split.  It was a wrong correction in commit
14bf01bb0599c89fc7f426d20353b76e12555308 to make this test for
TASK_TRACED instead.  It should have been changed when TASK_TRACED
was introducted and again when exit_state was introduced.

Signed-off-by: Roland McGrath 
Cc: Oleg Nesterov 
Cc: Alexey Dobriyan 
Cc: Kees Cook 
Acked-by: Scott James Remnant 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

param_sysfs_builtin memchr argument fix

2007-11-05T17:56:07+00:00

patch faf8c714f4508207a9c81cc94dafc76ed6680b44 in mainline.

If memchr argument is longer than strlen(kp->name), there will be some
weird result.

It will casuse duplicate filenames in sysfs for the "nousb".  kernel
warning messages are as bellow:

sysfs: duplicate filename 'usbcore' can not be created
WARNING: at fs/sysfs/dir.c:416 sysfs_add_one()
 [] sysfs_add_one+0xa0/0xe0
 [] create_dir+0x48/0xb0
 [] sysfs_create_dir+0x29/0x50
 [] create_dir+0x1b/0x50
 [] kobject_add+0x46/0x150
 [] kobject_init+0x3a/0x80
 [] kernel_param_sysfs_setup+0x50/0xb0
 [] param_sysfs_builtin+0xee/0x130
 [] param_sysfs_init+0x23/0x60
 [] __next_cpu+0x12/0x20
 [] kernel_init+0x0/0xb0
 [] kernel_init+0x0/0xb0
 [] do_initcalls+0x46/0x1e0
 [] create_proc_entry+0x52/0x90
 [] register_irq_proc+0x9c/0xc0
 [] proc_mkdir_mode+0x34/0x50
 [] kernel_init+0x0/0xb0
 [] kernel_init+0x62/0xb0
 [] kernel_thread_helper+0x7/0x14
 =======================
kobject_add failed for usbcore with -EEXIST, don't try to register things with the same name in the same directory.
 [] kobject_add+0xf6/0x150
 [] kernel_param_sysfs_setup+0x50/0xb0
 [] param_sysfs_builtin+0xee/0x130
 [] param_sysfs_init+0x23/0x60
 [] __next_cpu+0x12/0x20
 [] kernel_init+0x0/0xb0
 [] kernel_init+0x0/0xb0
 [] do_initcalls+0x46/0x1e0
 [] create_proc_entry+0x52/0x90
 [] register_irq_proc+0x9c/0xc0
 [] proc_mkdir_mode+0x34/0x50
 [] kernel_init+0x0/0xb0
 [] kernel_init+0x62/0xb0
 [] kernel_thread_helper+0x7/0x14
 =======================
Module 'usbcore' failed to be added to sysfs, error number -17
The system will be unstable now.

Signed-off-by: Dave Young 
Cc: Greg KH 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

genirq: suppress resend of level interrupts

2007-11-05T17:56:06+00:00

patch 2464286ace55b3abddfb9cc30ab95e2dac1de9a6 in mainline.

Level type interrupts are resent by the interrupt hardware when they are
still active at irq_enable().

Suppress the resend mechanism for interrupts marked as level.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Linus Torvalds 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman