linux-stable.git/fs/exec.c, branch linux-2.6.25.y

exec: fix stack excutability without PT_GNU_STACK

2008-07-24T16:14:08+00:00

commit 96a8e13ed44e380fc2bb6c711d74d5ba698c00b2 upstream

Kernel Bugzilla #11063 points out that on some architectures (e.g. x86_32)
exec'ing an ELF without a PT_GNU_STACK program header should default to an
executable stack; but this got broken by the unlimited argv feature because
stack vma is now created before the right personality has been established:
so breaking old binaries using nested function trampolines.

Therefore re-evaluate VM_STACK_FLAGS in setup_arg_pages, where stack
vm_flags used to be set, before the mprotect_fixup.  Checking through
our existing VM_flags, none would have changed since insert_vm_struct:
so this seems safer than finding a way through the personality labyrinth.

Reported-by: pageexec@freemail.hu
Signed-off-by: Hugh Dickins 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Allow ARG_MAX execve string space even with a small stack limit

2008-03-03T18:12:14+00:00

The new code that removed the limitation on the execve string size
(which was historically 32 pages) replaced it with a much softer limit
based on RLIMIT_STACK which is usually much larger than the traditional
limit.  See commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba ("mm:
variable length argument support") for details.

However, if you have a small stack limit (perhaps because you need lots
of stacks in a threaded environment), the new heuristic of allowing up
to 1/4th of RLIMIT_STACK to be used for argument and environment strings
could actually be smaller than the old limit.

So just say that it's ok to have up to ARG_MAX strings regardless of the
value of RLIMIT_STACK, and check the rlimit only when going over that
traditional limit.

(Of course, if you actually have a *really* small stack limit, the whole
stack itself will be limited before you hit ARG_MAX, but that has always
been true and is clearly the right behaviour anyway).

Acked-by: Carlos O'Donell 
Cc: Michael Kerrisk 
Cc: Peter Zijlstra 
Cc: Ollie Wild 
Signed-off-by: Linus Torvalds

Introduce path_put()

2008-02-15T05:13:33+00:00

* Add path_put() functions for releasing a reference to the dentry and
  vfsmount of a struct path in the right order

* Switch from path_release(nd) to path_put(&nd->path)

* Rename dput_path() to path_put_conditional()

[akpm@linux-foundation.org: fix cifs]
Signed-off-by: Jan Blunck 
Signed-off-by: Andreas Gruenbacher 
Acked-by: Christoph Hellwig 
Cc: 
Cc: Al Viro 
Cc: Steven French 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Embed a struct path into struct nameidata instead of nd->{dentry,mnt}

2008-02-15T05:13:33+00:00

This is the central patch of a cleanup series. In most cases there is no good
reason why someone would want to use a dentry for itself. This series reflects
that fact and embeds a struct path into nameidata.

Together with the other patches of this series
- it enforced the correct order of getting/releasing the reference count on
   pairs
- it prepares the VFS for stacking support since it is essential to have a
  struct path in every place where the stack can be traversed
- it reduces the overall code size:

without patch series:
   text    data     bss     dec     hex filename
5321639  858418  715768 6895825  6938d1 vmlinux

with patch series:
   text    data     bss     dec     hex filename
5320026  858418  715768 6894212  693284 vmlinux

This patch:

Switch from nd->{dentry,mnt} to nd->path.{dentry,mnt} everywhere.

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix cifs]
[akpm@linux-foundation.org: fix smack]
Signed-off-by: Jan Blunck 
Signed-off-by: Andreas Gruenbacher 
Acked-by: Christoph Hellwig 
Cc: Al Viro 
Cc: Casey Schaufler 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Allow executables larger than 2GB

2008-02-08T17:22:34+00:00

This allows us to use executables >2GB.

Based on a patch by Dave Anderson

Signed-off-by: Andi Kleen 
Cc: Dave Anderson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

aout: suppress A.OUT library support if !CONFIG_ARCH_SUPPORTS_AOUT

2008-02-08T17:22:30+00:00

Suppress A.OUT library support if CONFIG_ARCH_SUPPORTS_AOUT is not set.

Not all architectures support the A.OUT binfmt, so the ELF binfmt should not
be permitted to go looking for A.OUT libraries to load in such a case.  Not
only that, but under such conditions A.OUT core dumps are not produced either.

To make this work, this patch also does the following:

 (1) Makes the existence of the contents of linux/a.out.h contingent on
     CONFIG_ARCH_SUPPORTS_AOUT.

 (2) Renames dump_thread() to aout_dump_thread() as it's only called by A.OUT
     core dumping code.

 (3) Moves aout_dump_thread() into asm/a.out-core.h and makes it inline.  This
     is then included only where needed.  This means that this bit of arch
     code will be stored in the appropriate A.OUT binfmt module rather than
     the core kernel.

 (4) Drops A.OUT support for Blackfin (according to Mike Frysinger it's not
     needed) and FRV.

This patch depends on the previous patch to move STACK_TOP[_MAX] out of
asm/a.out.h and into asm/processor.h as they're required whether or not A.OUT
format is available.

[jdike@addtoit.com: uml: re-remove accidentally restored code]
Signed-off-by: David Howells 
Cc: 
Signed-off-by: Jeff Dike 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

ITIMER_REAL: convert to use struct pid

2008-02-08T17:22:29+00:00

signal_struct->tsk points to the ->group_leader and thus we have the nasty
code in de_thread() which has to change it and restart ->real_timer if the
leader is changed.

Use "struct pid *leader_pid" instead.  This also allows us to kill now
unneeded send_group_sig_info().

Signed-off-by: Oleg Nesterov 
Acked-by: "Eric W. Biederman" 
Cc: Davide Libenzi 
Cc: Pavel Emelyanov 
Acked-by: Roland McGrath 
Acked-by: Thomas Gleixner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

exec: rework the group exit and fix the race with kill

2008-02-05T17:44:07+00:00

As Roland pointed out, we have the very old problem with exec.  de_thread()
sets SIGNAL_GROUP_EXIT, kills other threads, changes ->group_leader and then
clears signal->flags.  All signals (even fatal ones) sent in this window
(which is not too small) will be lost.

With this patch exec doesn't abuse SIGNAL_GROUP_EXIT.  signal_group_exit(),
the new helper, should be used to detect exit_group() or exec() in progress.
It can have more users, but this patch does only strictly necessary changes.

Signed-off-by: Oleg Nesterov 
Cc: Davide Libenzi 
Cc: Ingo Molnar 
Cc: Robin Holt 
Cc: Roland McGrath 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

get_task_comm(): return the result

2008-02-05T17:44:07+00:00

It was dumb to make get_task_comm() return void.  Change it to return a
pointer to the resulting output for caller convenience.

Cc: Ulrich Drepper 
Cc: Ingo Molnar 
Cc: Roland McGrath 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

vfs: coredumping fix

2007-11-28T18:58:01+00:00

fix: http://bugzilla.kernel.org/show_bug.cgi?id=3043

only allow coredumping to the same uid that the coredumping
task runs under.

Signed-off-by: Ingo Molnar 
Acked-by: Alan Cox 
Acked-by: Christoph Hellwig 
Acked-by: Al Viro 
Signed-off-by: Linus Torvalds