linux-stable.git/arch/tile, branch v4.1.45

mm: larger stack guard gap, between vmas

2017-06-28T22:57:15+00:00

[ Upstream commit 1be7107fbe18eed3e319a6c3e83c78254b693acb ]

Stack guard page is a useful feature to reduce a risk of stack smashing
into a different mapping. We have been using a single page gap which
is sufficient to prevent having stack adjacent to a different mapping.
But this seems to be insufficient in the light of the stack usage in
userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
which is 256kB or stack strings with MAX_ARG_STRLEN.

This will become especially dangerous for suid binaries and the default
no limit for the stack size limit because those applications can be
tricked to consume a large portion of the stack and a single glibc call
could jump over the guard page. These attacks are not theoretical,
unfortunatelly.

Make those attacks less probable by increasing the stack guard gap
to 1MB (on systems with 4k pages; but make it depend on the page size
because systems with larger base pages might cap stack allocations in
the PAGE_SIZE units) which should cover larger alloca() and VLA stack
allocations. It is obviously not a full fix because the problem is
somehow inherent, but it should reduce attack space a lot.

One could argue that the gap size should be configurable from userspace,
but that can be done later when somebody finds that the new 1MB is wrong
for some special case applications.  For now, add a kernel command line
option (stack_guard_gap) to specify the stack gap size (in page units).

Implementation wise, first delete all the old code for stack guard page:
because although we could get away with accounting one extra page in a
stack vma, accounting a larger gap can break userspace - case in point,
a program run with "ulimit -S -v 20000" failed when the 1MB gap was
counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
and strict non-overcommit mode.

Instead of keeping gap inside the stack vma, maintain the stack guard
gap as a gap between vmas: using vm_start_gap() in place of vm_start
(or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
places which need to respect the gap - mainly arch_get_unmapped_area(),
and and the vma tree's subtree_gap support for that.

Original-patch-by: Oleg Nesterov 
Original-patch-by: Michal Hocko 
Signed-off-by: Hugh Dickins 
Acked-by: Michal Hocko 
Tested-by: Helge Deller  # parisc
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

tile/ptrace: Preserve previous registers for short regset write

2017-03-06T22:29:12+00:00

[ Upstream commit fd7c99142d77dc4a851879a66715abf12a3193fb ]

Ensure that if userspace supplies insufficient data to
PTRACE_SETREGSET to fill all the registers, the thread's old
registers are preserved.

Cc: stable@vger.kernel.org
Signed-off-by: Dave Martin 
Signed-off-by: Chris Metcalf 
Signed-off-by: Sasha Levin

signal: fix information leak in copy_siginfo_from_user32

2015-08-17T03:52:26+00:00

commit 3c00cb5e68dc719f2fc73a33b1b230aadfcb1309 upstream.

This function can leak kernel stack data when the user siginfo_t has a
positive si_code value.  The top 16 bits of si_code descibe which fields
in the siginfo_t union are active, but they are treated inconsistently
between copy_siginfo_from_user32, copy_siginfo_to_user32 and
copy_siginfo_to_user.

copy_siginfo_from_user32 is called from rt_sigqueueinfo and
rt_tgsigqueueinfo in which the user has full control overthe top 16 bits
of si_code.

This fixes the following information leaks:
x86:   8 bytes leaked when sending a signal from a 32-bit process to
       itself. This leak grows to 16 bytes if the process uses x32.
       (si_code = __SI_CHLD)
x86:   100 bytes leaked when sending a signal from a 32-bit process to
       a 64-bit process. (si_code = -1)
sparc: 4 bytes leaked when sending a signal from a 32-bit process to a
       64-bit process. (si_code = any)

parsic and s390 have similar bugs, but they are not vulnerable because
rt_[tg]sigqueueinfo have checks that prevent sending a positive si_code
to a different process.  These bugs are also fixed for consistency.

Signed-off-by: Amanieu d'Antras 
Cc: Oleg Nesterov 
Cc: Ingo Molnar 
Cc: Russell King 
Cc: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Chris Metcalf 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

tile: use free_bootmem_late() for initrd

2015-08-10T19:21:56+00:00

commit 3f81d2447b37ac697b3c600039f2c6b628c06e21 upstream.

We were previously using free_bootmem() and just getting lucky
that nothing too bad happened.

Signed-off-by: Chris Metcalf 
Signed-off-by: Greg Kroah-Hartman

tile: properly use node_isset() on a nodemask_t

2015-04-28T14:36:45+00:00

The code accidentally used cpu_isset() previously in one place
(though properly node_isset() elsewhere).

Signed-off-by: Chris Metcalf

Merge tag 'cpumask-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux

2015-04-20T17:19:03+00:00

Pull final removal of deprecated cpus_* cpumask functions from Rusty Russell:
 "This is the final removal (after several years!) of the obsolete
  cpus_* functions, prompted by their mis-use in staging.

  With these function removed, all cpu functions should only iterate to
  nr_cpu_ids, so we finally only allocate that many bits when cpumasks
  are allocated offstack"

* tag 'cpumask-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (25 commits)
  cpumask: remove __first_cpu / __next_cpu
  cpumask: resurrect CPU_MASK_CPU0
  linux/cpumask.h: add typechecking to cpumask_test_cpu
  cpumask: only allocate nr_cpumask_bits.
  Fix weird uses of num_online_cpus().
  cpumask: remove deprecated functions.
  mips: fix obsolete cpumask_of_cpu usage.
  x86: fix more deprecated cpu function usage.
  ia64: remove deprecated cpus_ usage.
  powerpc: fix deprecated CPU_MASK_CPU0 usage.
  CPU_MASK_ALL/CPU_MASK_NONE: remove from deprecated region.
  staging/lustre/o2iblnd: Don't use cpus_weight
  staging/lustre/libcfs: replace deprecated cpus_ calls with cpumask_
  staging/lustre/ptlrpc: Do not use deprecated cpus_* functions
  blackfin: fix up obsolete cpu function usage.
  parisc: fix up obsolete cpu function usage.
  tile: fix up obsolete cpu function usage.
  arm64: fix up obsolete cpu function usage.
  mips: fix up obsolete cpu function usage.
  x86: fix up obsolete cpu function usage.
  ...

Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile

2015-04-17T20:03:05+00:00

Pull arch/tile updates from Chris Metcalf:
 "These are mostly nohz_full changes, plus a smattering of minor fixes
  (notably a couple for ftrace)"

* git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
  tile: nohz: warn if nohz_full uses hypervisor shared cores
  tile: ftrace: fix function_graph tracer issues
  tile: map data region shadow of kernel as R/W
  tile: support CONTEXT_TRACKING and thus NOHZ_FULL
  tile: support arch_irq_work_raise
  arch: tile: fix null pointer dereference on pt_regs pointer
  tile/elf: reorganize notify_exec()
  tile: use si_int instead of si_ptr for compat_siginfo

tile: nohz: warn if nohz_full uses hypervisor shared cores

2015-04-17T18:01:41+00:00

The "hypervisor shared" cores are ones that the Tilera hypervisor
uses to receive interrupts to manage hypervisor-owned devices.
It's a bad idea to try to use those cores with nohz_full, since
they will get interrupted unpredictably -- and invisibly to Linux
tracing tools, since the interrupts are delivered at a higher
privilege level to the Tilera hypervisor.

Generate a clear warning at boot up that this doesn't end well
for the nohz_full cores in question.

Signed-off-by: Chris Metcalf

tile: ftrace: fix function_graph tracer issues

2015-04-17T18:01:38+00:00

- Add support for ARCH_SUPPORTS_FTRACE_OPS
- Replace the instruction in ftrace_call with the bundle {move r10, lr;
jal ftrace_stub}, so that the lr contains the right value after returning
from ftrace_stub.  An alternative fix might be to leave the instruction
in ftrace_call alone when it is being updated with ftrace_stub.

Signed-off-by: Tony Lu 
Signed-off-by: Chris Metcalf

tile: map data region shadow of kernel as R/W

2015-04-17T18:01:35+00:00

This is necessary for things like reading /proc/kcore, doing ftrace,
etc.  It happens by default when using huge pages to map the kernel
data, but not when using small pages.

Signed-off-by: Chris Metcalf