kernel/linux.git, branch v2.6.16.21

Linux 2.6.16.21

2006-06-20T08:55:00+00:00

[PATCH] xt_sctp: fix endless loop caused by 0 chunk length (CVE-2006-3085)

2006-06-20T08:54:53+00:00

Fix endless loop in the SCTP match similar to those already fixed in the SCTP conntrack helper (was CVE-2006-1527). Signed-off-by: Patrick McHardy Signed-off-by: Chris Wright

[PATCH] run_posix_cpu_timers: remove a bogus BUG_ON() (CVE-2006-2445)

2006-06-20T08:54:53+00:00

do_exit() clears ->it_##clock##_expires, but nothing prevents another cpu to attach the timer to exiting process after that. arm_timer() tries to protect against this race, but the check is racy. After exit_notify() does 'write_unlock_irq(&tasklist_lock)' and before do_exit() calls 'schedule() local timer interrupt can find tsk->exit_state != 0. If that state was EXIT_DEAD (or another cpu does sys_wait4) interrupted task has ->signal == NULL. At this moment exiting task has no pending cpu timers, they were cleanuped in __exit_signal()->posix_cpu_timers_exit{,_group}(), so we can just return from irq. John Stultz recently confirmed this bug, see http://marc.theaimsgroup.com/?l=linux-kernel&m=115015841413687 Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] check_process_timers: fix possible lockup

2006-06-20T08:54:52+00:00

If the local timer interrupt happens just after do_exit() sets PF_EXITING (and before it clears ->it_xxx_expires) run_posix_cpu_timers() will call check_process_timers() with tasklist_lock + ->siglock held and check_process_timers: t = tsk; do { .... do { t = next_thread(t); } while (unlikely(t->flags & PF_EXITING)); } while (t != tsk); the outer loop will never stop. Actually, the window is bigger. Another process can attach the timer after ->it_xxx_expires was cleared (see the next commit) and the 'if (PF_EXITING)' check in arm_timer() is racy (see the one after that). Signed-off-by: Oleg Nesterov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright

[PATCH] powerpc: Fix machine check problem on 32-bit kernels (CVE-2006-2448)

2006-06-20T08:54:52+00:00

This fixes a bug found by Dave Jones that means that it is possible for userspace to provoke a machine check on 32-bit kernels. This also fixes a couple of other places where I found similar problems by inspection. Signed-off-by: Paul Mackerras Signed-off-by: Chris Wright

Linux 2.6.16.20

2006-06-05T17:18:23+00:00

[PATCH] sbp2: fix check of return value of hpsb_allocate_and_register_addrspace

2006-06-05T17:18:15+00:00

I added a failure check in patch "sbp2: variable status FIFO address (fix login timeout)" --- alas for a wrong error value. This is a bug since Linux 2.6.16. Leads to NULL pointer dereference if the call failed, and bogus failure handling if call succeeded. Signed-off-by: Stefan Richter Signed-off-by: Chris Wright

[PATCH] sbp2: backport read_capacity workaround for iPod

2006-06-05T17:18:15+00:00

There is a firmware bug in several Apple iPods which prevents access to these iPods under certain conditions. The disk size reported by the iPod is one sector too big. Once access to the end of the disk is attempted, the iPod becomes inaccessible. This problem has been known for USB iPods for some time and has recently been discovered to exist with FireWire/USB combo iPods too. This patch is derived from the fix in Linux 2.6.17, commit e9a1c52c7b19d10342226c12f170d7ab644427e2, to be applicable to 2.6.16.x without prerequisite patches. It hard-wires a workaround for three known affected model numbers (those of 4th generation iPod, iPod Photo, iPod mini). Note: This patch lacks Linux 2.6.17's ability to enable and disable the workaround via a module parameter. Signed-off-by: Stefan Richter Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] x86_64: Don't do syscall exit tracing twice

2006-06-05T17:18:14+00:00

This fixes a regression from the earlier DOS fix for non canonical IRET addresses. It broke UML. int_ret_from_syscall already does syscall exit tracing, so no need to do it again in the caller. This caused problems for UML and some other special programs doing syscall interception. Signed-off-by: Andi Kleen Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] x86_64: x86_64 add crashdump trigger points

2006-06-05T17:18:14+00:00

o Start booting into the capture kernel after an Oops if system is in a unrecoverable state. System will boot into the capture kernel, if one is pre-loaded by the user, and capture the kernel core dump. o One of the following conditions should be true to trigger the booting of capture kernel. - panic_on_oops is set. - pid of current thread is 0 - pid of current thread is 1 - Oops happened inside interrupt context. Signed-off-by: Vivek Goyal Signed-off-by: Andi Kleen Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Chris Wright