1. 07 6月, 2014 6 次提交
  2. 05 6月, 2014 1 次提交
    • F
      sys_sgetmask/sys_ssetmask: add CONFIG_SGETMASK_SYSCALL · f6187769
      Fabian Frederick 提交于
      sys_sgetmask and sys_ssetmask are obsolete system calls no longer
      supported in libc.
      
      This patch replaces architecture related __ARCH_WANT_SYS_SGETMAX by expert
      mode configuration.That option is enabled by default for those
      architectures.
      Signed-off-by: NFabian Frederick <fabf@skynet.be>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f6187769
  3. 08 4月, 2014 1 次提交
  4. 19 2月, 2014 1 次提交
  5. 24 1月, 2014 1 次提交
  6. 09 11月, 2013 1 次提交
  7. 12 9月, 2013 1 次提交
    • M
      kernel-wide: fix missing validations on __get/__put/__copy_to/__copy_from_user() · 3ddc5b46
      Mathieu Desnoyers 提交于
      I found the following pattern that leads in to interesting findings:
      
        grep -r "ret.*|=.*__put_user" *
        grep -r "ret.*|=.*__get_user" *
        grep -r "ret.*|=.*__copy" *
      
      The __put_user() calls in compat_ioctl.c, ptrace compat, signal compat,
      since those appear in compat code, we could probably expect the kernel
      addresses not to be reachable in the lower 32-bit range, so I think they
      might not be exploitable.
      
      For the "__get_user" cases, I don't think those are exploitable: the worse
      that can happen is that the kernel will copy kernel memory into in-kernel
      buffers, and will fail immediately afterward.
      
      The alpha csum_partial_copy_from_user() seems to be missing the
      access_ok() check entirely.  The fix is inspired from x86.  This could
      lead to information leak on alpha.  I also noticed that many architectures
      map csum_partial_copy_from_user() to csum_partial_copy_generic(), but I
      wonder if the latter is performing the access checks on every
      architectures.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3ddc5b46
  8. 12 5月, 2013 1 次提交
    • C
      sigtimedwait: use freezable blocking call · a2d5f1f5
      Colin Cross 提交于
      Avoid waking up every thread sleeping in a sigtimedwait call during
      suspend and resume by calling a freezable blocking call.  Previous
      patches modified the freezer to avoid sending wakeups to threads
      that are blocked in freezable blocking calls.
      
      This call was selected to be converted to a freezable call because
      it doesn't hold any locks or release any resources when interrupted
      that might be needed by another freezing task or a kernel driver
      during suspend, and is a common site where idle userspace tasks are
      blocked.
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NColin Cross <ccross@android.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a2d5f1f5
  9. 01 5月, 2013 2 次提交
    • O
      coredump: only SIGKILL should interrupt the coredumping task · 403bad72
      Oleg Nesterov 提交于
      There are 2 well known and ancient problems with coredump/signals, and a
      lot of related bug reports:
      
      - do_coredump() clears TIF_SIGPENDING but of course this can't help
        if, say, SIGCHLD comes after that.
      
        In this case the coredump can fail unexpectedly. See for example
        wait_for_dump_helper()->signal_pending() check but there are other
        reasons.
      
      - At the same time, dumping a huge core on the slow media can take a
        lot of time/resources and there is no way to kill the coredumping
        task reliably. In particular this is not oom_kill-friendly.
      
      This patch tries to fix the 1st problem, and makes the preparation for the
      next changes.
      
      We add the new SIGNAL_GROUP_COREDUMP flag set by zap_threads() to indicate
      that this process dumps the core.  prepare_signal() checks this flag and
      nacks any signal except SIGKILL.
      
      Note that this check tries to be conservative, in the long term we should
      probably treat the SIGNAL_GROUP_EXIT case equally but this needs more
      discussion.  See marc.info/?l=linux-kernel&m=120508897917439
      
      Notes:
      	- recalc_sigpending() doesn't check SIGNAL_GROUP_COREDUMP.
      	  The patch assumes that dump_write/etc paths should never
      	  call it, but we can change it as well.
      
      	- There is another source of TIF_SIGPENDING, freezer. This
      	  will be addressed separately.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Tested-by: NMandeep Singh Baines <msb@chromium.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Neil Horman <nhorman@redhat.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      403bad72
    • V
      arc, print-fatal-signals: reduce duplicated information · 681a90ff
      Vineet Gupta 提交于
      After the recent generic debug info on dump_stack() and friends, arc
      is printing duplicate information on debug dumps.
      
       [ARCLinux]$ ./crash
       crash/50: potentially unexpected fatal signal 11.	<-- [1]
       /sbin/crash, TGID 50					<-- [2]
       Pid: 50, comm: crash Not tainted 3.9.0-rc4+ #132 	<-- [3]
       ...
      
      Remove them.
      
      [tj@kernel.org: updated patch desc]
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      681a90ff
  10. 18 4月, 2013 1 次提交
  11. 21 3月, 2013 1 次提交
  12. 14 3月, 2013 2 次提交
    • A
      kernel/signal.c: use __ARCH_HAS_SA_RESTORER instead of SA_RESTORER · 522cff14
      Andrew Morton 提交于
      __ARCH_HAS_SA_RESTORER is the preferred conditional for use in 3.9 and
      later kernels, per Kees.
      
      Cc: Emese Revfy <re.emese@gmail.com>
      Cc: Emese Revfy <re.emese@gmail.com>
      Cc: PaX Team <pageexec@freemail.hu>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Cc: Julien Tinnes <jln@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      522cff14
    • K
      signal: always clear sa_restorer on execve · 2ca39528
      Kees Cook 提交于
      When the new signal handlers are set up, the location of sa_restorer is
      not cleared, leaking a parent process's address space location to
      children.  This allows for a potential bypass of the parent's ASLR by
      examining the sa_restorer value returned when calling sigaction().
      
      Based on what should be considered "secret" about addresses, it only
      matters across the exec not the fork (since the VMAs haven't changed
      until the exec).  But since exec sets SIG_DFL and keeps sa_restorer,
      this is where it should be fixed.
      
      Given the few uses of sa_restorer, a "set" function was not written
      since this would be the only use.  Instead, we use
      __ARCH_HAS_SA_RESTORER, as already done in other places.
      
      Example of the leak before applying this patch:
      
        $ cat /proc/$$/maps
        ...
        7fb9f3083000-7fb9f3238000 r-xp 00000000 fd:01 404469 .../libc-2.15.so
        ...
        $ ./leak
        ...
        7f278bc74000-7f278be29000 r-xp 00000000 fd:01 404469 .../libc-2.15.so
        ...
        1 0 (nil) 0x7fb9f30b94a0
        2 4000000 (nil) 0x7f278bcaa4a0
        3 4000000 (nil) 0x7f278bcaa4a0
        4 0 (nil) 0x7fb9f30b94a0
        ...
      
      [akpm@linux-foundation.org: use SA_RESTORER for backportability]
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Reported-by: NEmese Revfy <re.emese@gmail.com>
      Cc: Emese Revfy <re.emese@gmail.com>
      Cc: PaX Team <pageexec@freemail.hu>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Cc: Julien Tinnes <jln@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2ca39528
  13. 13 3月, 2013 1 次提交
  14. 03 3月, 2013 1 次提交
  15. 28 2月, 2013 2 次提交
    • V
      kernel/signal.c: fix suboptimal printk usage · 5d1fadc1
      Valdis Kletnieks 提交于
      Several printk's were missing KERN_INFO and KERN_CONT flags.  In
      addition, a printk that was outside a #if/#endif should have been
      inside, which would result in stray blank line on non-x86 boxes.
      Signed-off-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5d1fadc1
    • A
      signal: allow to send any siginfo to itself · 66dd34ad
      Andrey Vagin 提交于
      The idea is simple.  We need to get the siginfo for each signal on
      checkpointing dump, and then return it back on restore.
      
      The first problem is that the kernel doesn't report complete siginfos to
      userspace.  In a signal handler the kernel strips SI_CODE from siginfo.
      When a siginfo is received from signalfd, it has a different format with
      fixed sizes of fields.  The interface of signalfd was extended.  If a
      signalfd is created with the flag SFD_RAW, it returns siginfo in a raw
      format.
      
      rt_sigqueueinfo looks suitable for restoring signals, but it can't send
      siginfo with a positive si_code, because these codes are reserved for
      the kernel.  In the real world each person has right to do anything with
      himself, so I think a process should able to send any siginfo to itself.
      
      This patch:
      
      The kernel prevents sending of siginfo with positive si_code, because
      these codes are reserved for kernel.  I think we can allow a task to
      send such a siginfo to itself.  This operation should not be dangerous.
      
      This functionality is required for restoring signals in
      checkpoint/restart.
      Signed-off-by: NAndrey Vagin <avagin@openvz.org>
      Cc: Serge Hallyn <serge.hallyn@canonical.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Reviewed-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      66dd34ad
  16. 14 2月, 2013 2 次提交
  17. 04 2月, 2013 11 次提交
  18. 28 1月, 2013 1 次提交
    • F
      cputime: Use accessors to read task cputime stats · 6fac4829
      Frederic Weisbecker 提交于
      This is in preparation for the full dynticks feature. While
      remotely reading the cputime of a task running in a full
      dynticks CPU, we'll need to do some extra-computation. This
      way we can account the time it spent tickless in userspace
      since its last cputime snapshot.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      6fac4829
  19. 23 1月, 2013 2 次提交
    • O
      ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL · 9899d11f
      Oleg Nesterov 提交于
      putreg() assumes that the tracee is not running and pt_regs_access() can
      safely play with its stack.  However a killed tracee can return from
      ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
      that debugger can actually read/modify the kernel stack until the tracee
      does SAVE_REST again.
      
      set_task_blockstep() can race with SIGKILL too and in some sense this
      race is even worse, the very fact the tracee can be woken up breaks the
      logic.
      
      As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
      call, this ensures that nobody can ever wakeup the tracee while the
      debugger looks at it.  Not only this fixes the mentioned problems, we
      can do some cleanups/simplifications in arch_ptrace() paths.
      
      Probably ptrace_unfreeze_traced() needs more callers, for example it
      makes sense to make the tracee killable for oom-killer before
      access_process_vm().
      
      While at it, add the comment into may_ptrace_stop() to explain why
      ptrace_stop() still can't rely on SIGKILL and signal_pending_state().
      Reported-by: NSalman Qazi <sqazi@google.com>
      Reported-by: NSuleiman Souhlal <suleiman@google.com>
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9899d11f
    • O
      ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up() · 910ffdb1
      Oleg Nesterov 提交于
      Cleanup and preparation for the next change.
      
      signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
      actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
      necessary mask.
      
      Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
      signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
      which adds __TASK_TRACED.
      
      This way ptrace_signal_wake_up() can work "inside" ptrace_request()
      even if the tracee doesn't have the TASK_WAKEKILL bit set.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      910ffdb1
  20. 06 1月, 2013 1 次提交