linux-stable.git/fs/proc/array.c, branch linux-2.6.27.y

proc: protect mm start_code/end_code in /proc/pid/stat

2011-04-30T14:53:22+00:00

commit 5883f57ca0008ffc93e09cbb9847a1928e50c6f3 upstream.

While mm->start_stack was protected from cross-uid viewing (commit
f83ce3e6b02d5 ("proc: avoid information leaks to non-privileged
processes")), the start_code and end_code values were not.  This would
allow the text location of a PIE binary to leak, defeating ASLR.

Note that the value "1" is used instead of "0" for a protected value since
"ps", "killall", and likely other readers of /proc/pid/stat, take
start_code of "0" to mean a kernel thread and will misbehave.  Thanks to
Brad Spengler for pointing this out.

Addresses CVE-2011-0726

Signed-off-by: Kees Cook 
Cc: Alexey Dobriyan 
Cc: David Howells 
Cc: Eugene Teo 
Cc: Martin Schwidefsky 
Cc: Brad Spengler 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

s390: remove task_show_regs

2011-04-30T14:53:06+00:00

commit 261cd298a8c363d7985e3482946edb4bfedacf98 upstream.

task_show_regs used to be a debugging aid in the early bringup days
of Linux on s390. /proc//status is a world readable file, it
is not a good idea to show the registers of a process. The only
correct fix is to remove task_show_regs.

Reported-by: Al Viro 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

proc: avoid information leaks to non-privileged processes

2009-05-08T21:54:36+00:00

commit f83ce3e6b02d5e48b3a43b001390e2b58820389d upstream.

By using the same test as is used for /proc/pid/maps and /proc/pid/smaps,
only allow processes that can ptrace() a given process to see information
that might be used to bypass address space layout randomization (ASLR).
These include eip, esp, wchan, and start_stack in /proc/pid/stat as well
as the non-symbolic output from /proc/pid/wchan.

ASLR can be bypassed by sampling eip as shown by the proof-of-concept
code at http://code.google.com/p/fuzzyaslr/ As part of a presentation
(http://www.cr0.org/paper/to-jt-linux-alsr-leak.pdf) esp and wchan were
also noted as possibly usable information leaks as well.  The
start_stack address also leaks potentially useful information.

Cc: Stable Team 
Signed-off-by: Jake Edge 
Acked-by: Arjan van de Ven 
Acked-by: "Eric W. Biederman" 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

sched: fix process time monotonicity

2008-09-05T16:14:35+00:00

Spencer reported a problem where utime and stime were going negative despite
the fixes in commit b27f03d4bdc145a09fb7b0c0e004b29f1ee555fa. The suspected
reason for the problem is that signal_struct maintains it's own utime and
stime (of exited tasks), these are not updated using the new task_utime()
routine, hence sig->utime can go backwards and cause the same problem
to occur (sig->utime, adds tsk->utime and not task_utime()). This patch
fixes the problem

TODO: using max(task->prev_utime, derived utime) works for now, but a more
generic solution is to implement cputime_max() and use the cputime_gt()
function for comparison.

Reported-by: spencer@bluehost.com
Signed-off-by: Balbir Singh 
Signed-off-by: Peter Zijlstra 
Signed-off-by: Ingo Molnar

tracehook: tracehook_tracer_task

2008-07-26T19:00:08+00:00

This adds the tracehook_tracer_task() hook to consolidate all forms of
"Who is using ptrace on me?" logic.  This is used for "TracerPid:" in
/proc and for permission checks.  We also clean up the selinux code the
called an identical accessor.

Signed-off-by: Roland McGrath 
Cc: Oleg Nesterov 
Reviewed-by: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

capabilities: remain source compatible with 32-bit raw legacy capability support.

2008-05-31T23:36:16+00:00

Source code out there hard-codes a notion of what the
_LINUX_CAPABILITY_VERSION #define means in terms of the semantics of the
raw capability system calls capget() and capset().  Its unfortunate, but
true.

Since the confusing header file has been in a released kernel, there is
software that is erroneously using 64-bit capabilities with the semantics
of 32-bit compatibilities.  These recently compiled programs may suffer
corruption of their memory when sys_getcap() overwrites more memory than
they are coded to expect, and the raising of added capabilities when using
sys_capset().

As such, this patch does a number of things to clean up the situation
for all. It

  1. forces the _LINUX_CAPABILITY_VERSION define to always retain its
     legacy value.

  2. adopts a new #define strategy for the kernel's internal
     implementation of the preferred magic.

  3. deprecates v2 capability magic in favor of a new (v3) magic
     number. The functionality of v3 is entirely equivalent to v2,
     the only difference being that the v2 magic causes the kernel
     to log a "deprecated" warning so the admin can find applications
     that may be using v2 inappropriately.

[User space code continues to be encouraged to use the libcap API which
protects the application from details like this.  libcap-2.10 is the first
to support v3 capabilities.]

Fixes issue reported in https://bugzilla.redhat.com/show_bug.cgi?id=447518.
Thanks to Bojan Smojver for the report.

[akpm@linux-foundation.org: s/depreciate/deprecate/g]
[akpm@linux-foundation.org: be robust about put_user size]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Andrew G. Morgan 
Cc: Serge E. Hallyn 
Cc: Bojan Smojver 
Cc: stable@kernel.org
Signed-off-by: Andrew Morton 
Signed-off-by: Chris Wright

capabilities: add bounding set to /proc/self/status

2008-05-13T15:02:24+00:00

There is currently no way to query the bounding set of another task.  As there
appears to be no security reason not to, and as Michael Kerrisk points out the
following valid reasons to do so exist:

* consistency (I can see all of the other per-thread/process sets in
  /proc/.../status)

* debugging -- I could imagine that it would make the job of debugging an
  application that uses capabilities a little simpler.

this patch adds the bounding set to /proc/self/status right after the
effective set.

Signed-off-by: Serge E. Hallyn 
Acked-by: Michael Kerrisk 
Acked-by: Andrew G. Morgan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] split linux/file.h

2008-05-01T17:08:16+00:00

Initial splitoff of the low-level stuff; taken to fdtable.h

Signed-off-by: Al Viro

tty_io: fix remaining pid struct locking

2008-04-30T15:29:40+00:00

This fixes the last couple of pid struct locking failures I know about.

[oleg@tv-sign.ru: clean up do_task_stat()]
Signed-off-by: Alan Cox 
Signed-off-by: Oleg Nesterov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

do_task_stat: don't take rcu_read_lock()

2008-04-30T15:29:34+00:00

lock_task_sighand() was changed, and do_task_stat() doesn't need
rcu_read_lock any longer.  sighand->siglock protects all "interesting"
fields.

Except: it doesn't protect ->tty->pgrp, but neither does rcu_read_lock(), this
should be fixed.

Signed-off-by: Oleg Nesterov 
Cc: "Eric W. Biederman" 
Cc: "Paul E. McKenney" 
Cc: Roland McGrath 
Cc: Alan Cox 
Cc: Pavel Emelyanov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds