Kernel patch to add rootdelay feature

This patch adds the 'rootdelay' option to the kernel
command-line boot options. The feature was backported
from the 2.6 kernel series. This allows for mounting
root filesystems which are located on devices whose
drivers are slow to load, such as USB mass-storage devices.

Example: 'rootdelay=10' tells the kernel tp wait 10
seconds before trying to mount the rootfs device.
[PATCH] Reintroduction i386 CONFIG_DUMMY_KEYB option

This re-activates an option making it possible to replace the PS2
keyboard driver by a dummy one still compatible with CONFIG_VT. The code
has been in the kernel for a long time, only the option was hidden ! It
also has an equivalent in 2.6.

Patch from Nick Warne <nick@linicks.net>
Signed-off-by: Willy Tarreau <willy@w.ods.org>
[PATCH] Backport of CVE-2005-2709 fix

 I've backported the fix for CVE-2005-2709 to 2.4 for Debian's 2.4
sarge kernel. Below is a patch against 2.4.32, in case one hasn't been
submitted to you yet. Please apply.

CVE-2005-2709

sysctl.c in Linux kernel before 2.6.14.1 allows local users to cause a
denial of service (kernel oops) and possibly execute code by opening an
interface file in /proc/sys/net/ipv4/conf/, waiting until the interface
is unregistered, then obtaining and modifying function pointers in
memory that was used for the ctl_table.

Signed-off-by: dann frazier <dannf@debian.org>
[PATCH] Fix ptrace self-attach rule (2.6 backport)

Patch-mainline: v2.6.14.2
Acked-by: Karsten Keil <kkeil@suse.de>
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/gregkh/linux-2.6.14.y.git;a=commitdiff;h=082d52c56f642d21b771a13221068d40915a1409

  [PATCH] Fix ptrace self-attach rule

  Before we did CLONE_THREAD, the way to check whether we were attaching
  to ourselves was to just check "current == task", but with CLONE_THREAD
  we should check that the thread group ID matches instead.

  Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] x86-64: user code panics kernel in exec.c (CVE-2005-2708)

There seems to be a local DoS in exec on AMD64 / linux 2.4
when the system is under memory pressure.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161925

Comment #9 From Dave Anderson  	 on 2005-08-31 14:36 EST

I don't particularly care for either patch suggestion. The problem is
that load_elf_binary() -- which is trying to load a legitimate ELF
binary, is returning -ENOEXEC back to search_binary_handler() because
load_elf_interp() has returned a BAD_ADDR:

        if (elf_interpreter) {
                if (interpreter_type == INTERPRETER_AOUT)
                        elf_entry = load_aout_interp(&interp_ex,
                                                     interpreter);
                else
                        elf_entry = load_elf_interp(&interp_elf_ex,
                                                    interpreter,
                                                    &interp_load_addr);

                if (BAD_ADDR(elf_entry)) {
                        printk(KERN_ERR "Unable to load interpreter\n");
                        send_sig(SIGSEGV, current, 0);
                        retval = -ENOEXEC; /* Nobody gets to see this, but.. */
                        goto out_free_dentry;
                }
                reloc_func_desc = interp_load_addr;

                allow_write_access(interpreter);
                fput(interpreter);
                kfree(elf_interpreter);
        }

and *because* search_binary_handler() sees the -ENOEXEC, it kicks off
the attempt to load the bogus module. And therein lies the problem, for
whatever reason, the modprobe process results in the double-fault, and
the original exec operation continues, and fails as it should. But that
all may be a red herring, since ENOEXEC with respect to execve means:

      ENOEXEC An  executable  is  not in a recognised format, is for the wrong
              architecture, or has some other format error that means it  can-
              not be executed.

However in this case, that's not at all true. It's legitimate, but the
attempt to load the /lib64/ld-linux-x86-64.so.2 interpreter into the
limited address space fails, and load_elf_interp() returns -ENOMEM. But
the ENOMEM is "lost" in the elf_entry variable. However, if -ENOMEM is
in fact returned back to search_binary_handler(), it all works just
fine. ENOMEM with respect to execve means:

       ENOMEM Insufficient kernel memory was available.

which isn't *exactly* what's going on here, but pretty close...

There's also the question of why the modprobe is failing, given that the
bogus module name doesn't exist. You would think that shouldn't cause
the kernel to double-fault. I mean do *all* of the request_module()
calls in the kernel require that the target module pre-exist? Since the
kernel seems to handle it differently/successfully on at least i386
and ia64, I haven't determined whether the request_module() is even
attempted on those architectures, or whether the operation fails in a
different code path.
[PATCH] do not mark init_idle() __init

Zbigniew Baniewski reported a panic at boot when using
CONFIG_BLK_DEV_IDEDISK=m. The code crashed when calling init_idle().

PaX Team brought to my attention that init_idle() is marked __init,
and is called from cpu_idle() (which is not) itself called from
rest_init() (which is not either), on top of which there is a big
shiny comment :

 * We need to finalize in a non-__init function or else race conditions
 * between the root thread and the init thread may cause start_kernel to
 * be reaped by free_initmem before the root thread has proceeded to
 * cpu_idle.

Indeed. Simply removing __init from init_idle fixed the panic.
[PATCH] prevent SIGCONT from waking up a PTRACED process (CVE-2007-4774)

Tavis Ormandy discovered that it was possible to bypass systrace policies
by flooding the ptraced process with SIGCONT signals. The same is possible
with SIGKILL, but obviously the attacker has to finely adjust its target
as it can only shoot once.

This issue was assigned identifier CVE-2007-4774.

The following patch fixes the SIGCONT case and adds some documentation for
authors of monitoring programs such as systrace.

Signed-off-by: Willy Tarreau <w@1wt.eu>
Acked-by: Tavis Ormandy <taviso@sdf.lonestar.org>
exit_notify: kill the wrong capable(CAP_KILL) check

[backport of 2.6 commit 432870dab85a2f69dc417022646cb9a70acf7f94]

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 <oleg@redhat.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
Acked-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
copy_process: fix CLONE_PARENT && parent_exec_id interaction

[backport of 2.6 commit 2d5516cbb9daf7d0e342a2e3b0fc6f8c39a81205]

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 <oleg@redhat.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Serge E. Hallyn <serge@hallyn.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
exit_notify: fix regression uncovered by the CAP_KILL fix

Patch 3551c6a671cd7aa17ef6254276000ab8f3171708 silently uncovered
a bug waiting to strike. The problem is that request_module() does
not set the modprobe task's exit_signal and does not expect it to
send a signal when it dies, as it does a waitpid(pid, NULL, __WCLONE).

During exit_notify(), exit signal 0 was not changed when modprobe
exited because modprobe had CAP_KILL set ! Since we removed that
test, modprobe sees its exit_signal assigned to SIGCHLD, which does
not please its parent and leaves modprobe zombies everywhere.

The correct fix consists in not setting exit_signal to SIGCHLD if
exit_signal was not previously set.

This simple reproducer easily triggers the bug, with CONFIG_IPV6=m :

  #include <stdio.h>
  #include <sys/socket.h>
  #include <netinet/in.h>

  main() {
	socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP);
        getchar();
  }

It causes the following line to be displayed in kernel logs :

  request_module[net-pf-10]: waitpid(371,...) failed, errno 1

A modprobe zombie lies around until the reproducer dies.

Special thanks to Michael Niehren for reporting the issue and helping
in quickly narrowing the problem down by testing patches.

Signed-off-by: Willy Tarreau <w@1wt.eu>
kernel/resource.c: fix sign extension in reserve_setup()

[backported from 2.6 commit 01a6403211958921247f4e65b16376e6ec706a0d]

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 <rui.zhang@intel.com>
Reported-by: Leann Ogasawara <leann@ubuntu.com>
Cc: Pierre Ossman <drzeus@drzeus.cx>
Reported-by: <pablomme@googlemail.com>
Tested-by: <pablomme@googlemail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[WT: 2.4 uses unsigned long instead of resource_size_t but the
 problem is the same on 64-bit archs]
Signed-off-by: Willy Tarreau <w@1wt.eu>
do_sigaltstack: avoid copying 'stack_t' as a structure to user space

(backported from 2.6 commit 0083fc2c50e6c5127c2802ad323adf8143ab7856)

Ulrich Drepper correctly points out that there is generally padding in
the structure on 64-bit hosts, and that copying the structure from
kernel to user space can leak information from the kernel stack in those
padding bytes.

Avoid the whole issue by just copying the three members one by one
instead, which also means that the function also can avoid the need for
a stack frame.  This also happens to match how we copy the new structure
from user space, so it all even makes sense.

[ The obvious solution of adding a memset() generates horrid code, gcc
  does really stupid things. ]

Reported-by: Ulrich Drepper <drepper@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
ext3: ext3_symlink should use GFP_NOFS allocations inside

This is a backport of 2.6 patch 0adb25d2e71ab047423d6fc63d5d184590d0a66f.

Sascha Umlang reported the exact same issue and traces and confirmed
that this backport fixes the issue for him.

Signed-off-by: Willy Tarreau <w@1wt.eu>
do_exit(): make sure that we run with get_fs() == USER_DS

If a user manages to trigger an oops with fs set to KERNEL_DS, fs is not
otherwise reset before do_exit().  do_exit may later (via mm_release in
fork.c) do a put_user to a user-controlled address, potentially allowing
a user to leverage an oops into a controlled write into kernel memory.

This is only triggerable in the presence of another bug, but this
potentially turns a lot of DoS bugs into privilege escalations, so it's
worth fixing.  I have proof-of-concept code which uses this bug along
with CVE-2010-3849 to write a zero to an arbitrary kernel address, so
I've tested that this is not theoretical.

A more logical place to put this fix might be when we know an oops has
occurred, before we call do_exit(), but that would involve changing
every architecture, in multiple places.

Let's just stick it in do_exit instead.

(backported from 2.6 commit 33dd94ae1ccbfb7bf0fb6c692bc3d1c4269e6177)

[akpm@linux-foundation.org: update code comment]
Signed-off-by: Nelson Elhage <nelhage@ksplice.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code

Userland should be able to trust the pid and uid of the sender of a
signal if the si_code is SI_TKILL.

Unfortunately, the kernel has historically allowed sigqueueinfo() to
send any si_code at all (as long as it was negative - to distinguish it
from kernel-generated signals like SIGILL etc), so it could spoof a
SI_TKILL with incorrect siginfo values.

Happily, it looks like glibc has always set si_code to the appropriate
SI_QUEUE, so there are probably no actual user code that ever uses
anything but the appropriate SI_QUEUE flag.

So just tighten the check for si_code (we used to allow any negative
value), and add a (one-time) warning in case there are binaries out
there that might depend on using other si_code values.

Signed-off-by: Julien Tinnes <jln@google.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[ WT: removed the WARN_ON_ONCE() which is not available in 2.4 and not critical ]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Relax si_code check in rt_sigqueueinfo and rt_tgsigqueueinfo

commit 243b422af9ea9af4ead07a8ad54c90d4f9b6081a upstream

Commit da48524eb206 ("Prevent rt_sigqueueinfo and rt_tgsigqueueinfo
from spoofing the signal code") made the check on si_code too strict.
There are several legitimate places where glibc wants to queue a
negative si_code different from SI_QUEUE:

 - This was first noticed with glibc's aio implementation, which wants
   to queue a signal with si_code SI_ASYNCIO; the current kernel
   causes glibc's tst-aio4 test to fail because rt_sigqueueinfo()
   fails with EPERM.

 - Further examination of the glibc source shows that getaddrinfo_a()
   wants to use SI_ASYNCNL (which the kernel does not even define).
   The timer_create() fallback code wants to queue signals with SI_TIMER.

As suggested by Oleg Nesterov <oleg@redhat.com>, loosen the check to
forbid only the problematic SI_TKILL case.

Reported-by: Klaus Dittrich <kladit@arcor.de>
Acked-by: Julien Tinnes <jln@google.com>
Cc: <stable@kernel.org>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Tested-by: Krzysztof Mazur <krzysiek@podlesie.net>
Signed-off-by: Willy Tarreau <w@1wt.eu>
[PATCH] i386: fix overflow in vmap on an x86 system which has more than 4GB memory.

(max_mapnr << PAGE_SHIFT) would overflow on a system which has
4GB memory or more, and so could cause vmap to fail every time.

Signed-off-by: Michael Chen <micche@ati.com>
Signed-off-by: Hugh Dickins <hugh@veritas.com>
[PATCH] Fix incorrect user space access locking in mincore() (CVE-2006-4814)

Fix incorrect user space access locking in mincore()

Doug Chapman noticed that mincore() will do a "copy_to_user()" of the
result while holding the mmap semaphore for reading, which is a big
no-no.  While a recursive read-lock on a semaphore in the case of a page
fault happens to work, we don't actually allow them due to deadlock
scenarios with writers due to fairness issues.

Doug and Marcel sent in a patch to fix it, but I decided to just rewrite
the mess instead - not just fixing the locking problem, but making the
code smaller and (imho) much easier to understand.

Hugh "ported" it to 2.4:
please note two slight changes to behaviour under error conditions:

(a) mincore used to report -EINVAL if input len was so big that the
given area wrapped: that shouldn't be a distinct case from crossing
a hole in the address space, 2.6.11 corrected the error to -ENOMEM,
and this patch extends that correction to 2.4.

(b) mincore used to report -ENOMEM if the given area crossed a hole
in the address space, but continued to fill in the vector for file-
backed regions above - yet didn't fill the vector with non-present
entries for the hole, just ignored it.  This patch continues to
report -ENOMEM if the given area crosses a hole in the address
space, but simply stops filling the vector at that point.  We
doubt any app could be relying on the previous weird behaviour.

Cc: Doug Chapman <dchapman@redhat.com>
Cc: Marcel Holtmann <holtmann@redhat.com>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Hugh Dickins <hugh@veritas.com>
[PATCH] prevent do_brk() from allocating below mmap_min_addr

This is the 2.4 equivalent of the following 2.6 patch by Eric Paris :
ecaf18c15aac8bb9bed7b7aa0e382fe252e275d5

Given a specifically crafted binary do_brk() can be used to get low
pages available in userspace virtually memory and can thus be used to
circumvent the mmap_min_addr low memory protection.  Add security checks
in do_brk().

Signed-off-by: Willy Tarreau <w@1wt.eu>
The gzip description is as good as the ChangeLog says it is -: "Set n to
length of v, to detect improper tables" and "Don't accidentally grow j
past z". The return 2 instead of the return 0 is so that we actually
error out if we also get inproper tables (for some reason the code
returned "OK" in such cases).

Fix outstanding security bugs in the Linux zlib implementations. See:

a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html
b) http://bugs.gentoo.org/show_bug.cgi?id=94584

Signed-off-by: Tim Yamin <plasmaroo@gentoo.org>
Signed-off-by: Tavis Ormandy <taviso@gentoo.org>