2005-04-17 02:20:36 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* PARISC specific syscalls
|
|
|
|
*
|
|
|
|
* Copyright (C) 1999-2003 Matthew Wilcox <willy at parisc-linux.org>
|
|
|
|
* Copyright (C) 2000-2003 Paul Bame <bame at parisc-linux.org>
|
|
|
|
* Copyright (C) 2001 Thomas Bogendoerfer <tsbogend at parisc-linux.org>
|
2014-02-01 01:19:52 +04:00
|
|
|
* Copyright (C) 1999-2014 Helge Deller <deller@gmx.de>
|
2005-04-17 02:20:36 +04:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
*/
|
|
|
|
|
2016-12-24 22:46:01 +03:00
|
|
|
#include <linux/uaccess.h>
|
2014-02-01 01:19:52 +04:00
|
|
|
#include <asm/elf.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
#include <linux/file.h>
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/linkage.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/mman.h>
|
2017-02-08 20:51:30 +03:00
|
|
|
#include <linux/sched/signal.h>
|
2017-02-08 20:51:31 +03:00
|
|
|
#include <linux/sched/mm.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
#include <linux/shm.h>
|
|
|
|
#include <linux/syscalls.h>
|
2006-08-27 19:12:13 +04:00
|
|
|
#include <linux/utsname.h>
|
|
|
|
#include <linux/personality.h>
|
2014-02-01 01:19:52 +04:00
|
|
|
#include <linux/random.h>
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2014-02-01 01:19:52 +04:00
|
|
|
/* we construct an artificial offset for the mapping based on the physical
|
|
|
|
* address of the kernel mapping variable */
|
|
|
|
#define GET_LAST_MMAP(filp) \
|
|
|
|
(filp ? ((unsigned long) filp->f_mapping) >> 8 : 0UL)
|
|
|
|
#define SET_LAST_MMAP(filp, val) \
|
|
|
|
{ /* nothing */ }
|
|
|
|
|
|
|
|
static int get_offset(unsigned int last_mmap)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2014-04-09 21:49:28 +04:00
|
|
|
return (last_mmap & (SHM_COLOUR-1)) >> PAGE_SHIFT;
|
2014-02-01 01:19:52 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2014-02-01 01:19:52 +04:00
|
|
|
static unsigned long shared_align_offset(unsigned int last_mmap,
|
|
|
|
unsigned long pgoff)
|
|
|
|
{
|
|
|
|
return (get_offset(last_mmap) + pgoff) << PAGE_SHIFT;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2014-02-01 01:19:52 +04:00
|
|
|
static inline unsigned long COLOR_ALIGN(unsigned long addr,
|
|
|
|
unsigned int last_mmap, unsigned long pgoff)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2014-04-09 21:49:28 +04:00
|
|
|
unsigned long base = (addr+SHM_COLOUR-1) & ~(SHM_COLOUR-1);
|
|
|
|
unsigned long off = (SHM_COLOUR-1) &
|
2014-02-01 01:19:52 +04:00
|
|
|
(shared_align_offset(last_mmap, pgoff) << PAGE_SHIFT);
|
|
|
|
|
|
|
|
return base + off;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2014-02-01 01:19:52 +04:00
|
|
|
/*
|
|
|
|
* Top of mmap area (just below the process stack).
|
|
|
|
*/
|
|
|
|
|
2018-04-11 02:34:53 +03:00
|
|
|
/*
|
|
|
|
* When called from arch_get_unmapped_area(), rlim_stack will be NULL,
|
|
|
|
* indicating that "current" should be used instead of a passed-in
|
|
|
|
* value from the exec bprm as done with arch_pick_mmap_layout().
|
|
|
|
*/
|
|
|
|
static unsigned long mmap_upper_limit(struct rlimit *rlim_stack)
|
parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
locale-gen on Debian showed a strange problem on parisc:
mmap2(NULL, 536870912, PROT_NONE, MAP_SHARED, 3, 0) = 0x42a54000
mmap2(0x42a54000, 103860, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)
Basically it was just trying to re-mmap() a file at the same address
which it was given by a previous mmap() call. But this remapping failed
with EINVAL.
The problem is, that when MAP_FIXED and MAP_SHARED flags were used, we didn't
included the mapping-based offset when we verified the alignment of the given
fixed address against the offset which we calculated it in the previous call.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: <stable@vger.kernel.org> # 3.10+
2013-11-21 02:07:42 +04:00
|
|
|
{
|
2014-02-01 01:19:52 +04:00
|
|
|
unsigned long stack_base;
|
parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
locale-gen on Debian showed a strange problem on parisc:
mmap2(NULL, 536870912, PROT_NONE, MAP_SHARED, 3, 0) = 0x42a54000
mmap2(0x42a54000, 103860, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)
Basically it was just trying to re-mmap() a file at the same address
which it was given by a previous mmap() call. But this remapping failed
with EINVAL.
The problem is, that when MAP_FIXED and MAP_SHARED flags were used, we didn't
included the mapping-based offset when we verified the alignment of the given
fixed address against the offset which we calculated it in the previous call.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: <stable@vger.kernel.org> # 3.10+
2013-11-21 02:07:42 +04:00
|
|
|
|
2014-05-01 01:26:02 +04:00
|
|
|
/* Limit stack size - see setup_arg_pages() in fs/exec.c */
|
2018-04-11 02:34:53 +03:00
|
|
|
stack_base = rlim_stack ? rlim_stack->rlim_max
|
|
|
|
: rlimit_max(RLIMIT_STACK);
|
2014-05-01 01:26:02 +04:00
|
|
|
if (stack_base > STACK_SIZE_MAX)
|
|
|
|
stack_base = STACK_SIZE_MAX;
|
2014-02-01 01:19:52 +04:00
|
|
|
|
2015-05-11 23:01:27 +03:00
|
|
|
/* Add space for stack randomization. */
|
2019-04-04 09:26:22 +03:00
|
|
|
if (current->flags & PF_RANDOMIZE)
|
|
|
|
stack_base += (STACK_RND_MASK << PAGE_SHIFT);
|
2015-05-11 23:01:27 +03:00
|
|
|
|
2014-02-01 01:19:52 +04:00
|
|
|
return PAGE_ALIGN(STACK_TOP - stack_base);
|
parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
locale-gen on Debian showed a strange problem on parisc:
mmap2(NULL, 536870912, PROT_NONE, MAP_SHARED, 3, 0) = 0x42a54000
mmap2(0x42a54000, 103860, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)
Basically it was just trying to re-mmap() a file at the same address
which it was given by a previous mmap() call. But this remapping failed
with EINVAL.
The problem is, that when MAP_FIXED and MAP_SHARED flags were used, we didn't
included the mapping-based offset when we verified the alignment of the given
fixed address against the offset which we calculated it in the previous call.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: <stable@vger.kernel.org> # 3.10+
2013-11-21 02:07:42 +04:00
|
|
|
}
|
|
|
|
|
2014-02-01 01:19:52 +04:00
|
|
|
|
|
|
|
unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
|
|
|
|
unsigned long len, unsigned long pgoff, unsigned long flags)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
2014-02-01 01:19:52 +04:00
|
|
|
struct mm_struct *mm = current->mm;
|
mm: larger stack guard gap, between vmas
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 <oleg@redhat.com>
Original-patch-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Tested-by: Helge Deller <deller@gmx.de> # parisc
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-19 14:03:24 +03:00
|
|
|
struct vm_area_struct *vma, *prev;
|
2014-02-01 01:19:52 +04:00
|
|
|
unsigned long task_size = TASK_SIZE;
|
|
|
|
int do_color_align, last_mmap;
|
2013-02-28 05:02:40 +04:00
|
|
|
struct vm_unmapped_area_info info;
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2014-02-01 01:19:52 +04:00
|
|
|
if (len > task_size)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
do_color_align = 0;
|
|
|
|
if (filp || (flags & MAP_SHARED))
|
|
|
|
do_color_align = 1;
|
|
|
|
last_mmap = GET_LAST_MMAP(filp);
|
|
|
|
|
|
|
|
if (flags & MAP_FIXED) {
|
|
|
|
if ((flags & MAP_SHARED) && last_mmap &&
|
|
|
|
(addr - shared_align_offset(last_mmap, pgoff))
|
2014-04-09 21:49:28 +04:00
|
|
|
& (SHM_COLOUR - 1))
|
2014-02-01 01:19:52 +04:00
|
|
|
return -EINVAL;
|
|
|
|
goto found_addr;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (addr) {
|
|
|
|
if (do_color_align && last_mmap)
|
|
|
|
addr = COLOR_ALIGN(addr, last_mmap, pgoff);
|
|
|
|
else
|
|
|
|
addr = PAGE_ALIGN(addr);
|
|
|
|
|
mm: larger stack guard gap, between vmas
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 <oleg@redhat.com>
Original-patch-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Tested-by: Helge Deller <deller@gmx.de> # parisc
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-19 14:03:24 +03:00
|
|
|
vma = find_vma_prev(mm, addr, &prev);
|
2014-02-01 01:19:52 +04:00
|
|
|
if (task_size - len >= addr &&
|
mm: larger stack guard gap, between vmas
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 <oleg@redhat.com>
Original-patch-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Tested-by: Helge Deller <deller@gmx.de> # parisc
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-19 14:03:24 +03:00
|
|
|
(!vma || addr + len <= vm_start_gap(vma)) &&
|
|
|
|
(!prev || addr >= vm_end_gap(prev)))
|
2014-02-01 01:19:52 +04:00
|
|
|
goto found_addr;
|
|
|
|
}
|
|
|
|
|
2013-02-28 05:02:40 +04:00
|
|
|
info.flags = 0;
|
|
|
|
info.length = len;
|
2014-02-01 01:19:52 +04:00
|
|
|
info.low_limit = mm->mmap_legacy_base;
|
2018-04-11 02:34:53 +03:00
|
|
|
info.high_limit = mmap_upper_limit(NULL);
|
2014-04-09 21:49:28 +04:00
|
|
|
info.align_mask = last_mmap ? (PAGE_MASK & (SHM_COLOUR - 1)) : 0;
|
2014-02-01 01:19:52 +04:00
|
|
|
info.align_offset = shared_align_offset(last_mmap, pgoff);
|
|
|
|
addr = vm_unmapped_area(&info);
|
|
|
|
|
|
|
|
found_addr:
|
|
|
|
if (do_color_align && !last_mmap && !(addr & ~PAGE_MASK))
|
|
|
|
SET_LAST_MMAP(filp, addr - (pgoff << PAGE_SHIFT));
|
|
|
|
|
|
|
|
return addr;
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
2014-02-01 01:19:52 +04:00
|
|
|
unsigned long
|
|
|
|
arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
|
|
|
|
const unsigned long len, const unsigned long pgoff,
|
|
|
|
const unsigned long flags)
|
2005-04-17 02:20:36 +04:00
|
|
|
{
|
mm: larger stack guard gap, between vmas
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 <oleg@redhat.com>
Original-patch-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Tested-by: Helge Deller <deller@gmx.de> # parisc
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-19 14:03:24 +03:00
|
|
|
struct vm_area_struct *vma, *prev;
|
2014-02-01 01:19:52 +04:00
|
|
|
struct mm_struct *mm = current->mm;
|
|
|
|
unsigned long addr = addr0;
|
|
|
|
int do_color_align, last_mmap;
|
|
|
|
struct vm_unmapped_area_info info;
|
|
|
|
|
|
|
|
/* requested length too big for entire address space */
|
2005-04-17 02:20:36 +04:00
|
|
|
if (len > TASK_SIZE)
|
|
|
|
return -ENOMEM;
|
2014-02-01 01:19:52 +04:00
|
|
|
|
|
|
|
do_color_align = 0;
|
|
|
|
if (filp || (flags & MAP_SHARED))
|
|
|
|
do_color_align = 1;
|
|
|
|
last_mmap = GET_LAST_MMAP(filp);
|
|
|
|
|
2013-02-03 03:44:59 +04:00
|
|
|
if (flags & MAP_FIXED) {
|
2014-02-01 01:19:52 +04:00
|
|
|
if ((flags & MAP_SHARED) && last_mmap &&
|
|
|
|
(addr - shared_align_offset(last_mmap, pgoff))
|
2014-04-09 21:49:28 +04:00
|
|
|
& (SHM_COLOUR - 1))
|
2013-02-03 03:44:59 +04:00
|
|
|
return -EINVAL;
|
2014-02-01 01:19:52 +04:00
|
|
|
goto found_addr;
|
2013-02-03 03:44:59 +04:00
|
|
|
}
|
2005-04-17 02:20:36 +04:00
|
|
|
|
2014-02-01 01:19:52 +04:00
|
|
|
/* requesting a specific address */
|
|
|
|
if (addr) {
|
|
|
|
if (do_color_align && last_mmap)
|
|
|
|
addr = COLOR_ALIGN(addr, last_mmap, pgoff);
|
|
|
|
else
|
|
|
|
addr = PAGE_ALIGN(addr);
|
mm: larger stack guard gap, between vmas
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 <oleg@redhat.com>
Original-patch-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Tested-by: Helge Deller <deller@gmx.de> # parisc
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-19 14:03:24 +03:00
|
|
|
|
|
|
|
vma = find_vma_prev(mm, addr, &prev);
|
2014-02-01 01:19:52 +04:00
|
|
|
if (TASK_SIZE - len >= addr &&
|
mm: larger stack guard gap, between vmas
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 <oleg@redhat.com>
Original-patch-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Tested-by: Helge Deller <deller@gmx.de> # parisc
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-19 14:03:24 +03:00
|
|
|
(!vma || addr + len <= vm_start_gap(vma)) &&
|
|
|
|
(!prev || addr >= vm_end_gap(prev)))
|
2014-02-01 01:19:52 +04:00
|
|
|
goto found_addr;
|
|
|
|
}
|
|
|
|
|
|
|
|
info.flags = VM_UNMAPPED_AREA_TOPDOWN;
|
|
|
|
info.length = len;
|
|
|
|
info.low_limit = PAGE_SIZE;
|
|
|
|
info.high_limit = mm->mmap_base;
|
2014-04-09 21:49:28 +04:00
|
|
|
info.align_mask = last_mmap ? (PAGE_MASK & (SHM_COLOUR - 1)) : 0;
|
2014-02-01 01:19:52 +04:00
|
|
|
info.align_offset = shared_align_offset(last_mmap, pgoff);
|
|
|
|
addr = vm_unmapped_area(&info);
|
|
|
|
if (!(addr & ~PAGE_MASK))
|
|
|
|
goto found_addr;
|
|
|
|
VM_BUG_ON(addr != -ENOMEM);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A failed mmap() very likely causes application failure,
|
|
|
|
* so fall back to the bottom-up function here. This scenario
|
|
|
|
* can happen with large stack limits and large mmap()
|
|
|
|
* allocations.
|
|
|
|
*/
|
|
|
|
return arch_get_unmapped_area(filp, addr0, len, pgoff, flags);
|
|
|
|
|
|
|
|
found_addr:
|
|
|
|
if (do_color_align && !last_mmap && !(addr & ~PAGE_MASK))
|
|
|
|
SET_LAST_MMAP(filp, addr - (pgoff << PAGE_SHIFT));
|
parisc: fix mmap(MAP_FIXED|MAP_SHARED) to already mmapped address
locale-gen on Debian showed a strange problem on parisc:
mmap2(NULL, 536870912, PROT_NONE, MAP_SHARED, 3, 0) = 0x42a54000
mmap2(0x42a54000, 103860, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument)
Basically it was just trying to re-mmap() a file at the same address
which it was given by a previous mmap() call. But this remapping failed
with EINVAL.
The problem is, that when MAP_FIXED and MAP_SHARED flags were used, we didn't
included the mapping-based offset when we verified the alignment of the given
fixed address against the offset which we calculated it in the previous call.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: <stable@vger.kernel.org> # 3.10+
2013-11-21 02:07:42 +04:00
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
return addr;
|
|
|
|
}
|
|
|
|
|
2014-02-01 01:19:52 +04:00
|
|
|
static int mmap_is_legacy(void)
|
|
|
|
{
|
|
|
|
if (current->personality & ADDR_COMPAT_LAYOUT)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
/* parisc stack always grows up - so a unlimited stack should
|
|
|
|
* not be an indicator to use the legacy memory layout.
|
|
|
|
* if (rlimit(RLIMIT_STACK) == RLIM_INFINITY)
|
|
|
|
* return 1;
|
|
|
|
*/
|
|
|
|
|
|
|
|
return sysctl_legacy_va_layout;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long mmap_rnd(void)
|
|
|
|
{
|
|
|
|
unsigned long rnd = 0;
|
|
|
|
|
2016-10-16 01:02:27 +03:00
|
|
|
if (current->flags & PF_RANDOMIZE)
|
|
|
|
rnd = get_random_int() & MMAP_RND_MASK;
|
|
|
|
|
2014-02-01 01:19:52 +04:00
|
|
|
return rnd << PAGE_SHIFT;
|
|
|
|
}
|
|
|
|
|
2016-10-16 01:02:27 +03:00
|
|
|
unsigned long arch_mmap_rnd(void)
|
|
|
|
{
|
|
|
|
return (get_random_int() & MMAP_RND_MASK) << PAGE_SHIFT;
|
|
|
|
}
|
|
|
|
|
2014-02-01 01:19:52 +04:00
|
|
|
static unsigned long mmap_legacy_base(void)
|
|
|
|
{
|
|
|
|
return TASK_UNMAPPED_BASE + mmap_rnd();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function, called very early during the creation of a new
|
|
|
|
* process VM image, sets up which VM layout function to use:
|
|
|
|
*/
|
2018-04-11 02:34:53 +03:00
|
|
|
void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
|
2014-02-01 01:19:52 +04:00
|
|
|
{
|
|
|
|
mm->mmap_legacy_base = mmap_legacy_base();
|
2018-04-11 02:34:53 +03:00
|
|
|
mm->mmap_base = mmap_upper_limit(rlim_stack);
|
2014-02-01 01:19:52 +04:00
|
|
|
|
|
|
|
if (mmap_is_legacy()) {
|
|
|
|
mm->mmap_base = mm->mmap_legacy_base;
|
|
|
|
mm->get_unmapped_area = arch_get_unmapped_area;
|
|
|
|
} else {
|
|
|
|
mm->get_unmapped_area = arch_get_unmapped_area_topdown;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-04-17 02:20:36 +04:00
|
|
|
asmlinkage unsigned long sys_mmap2(unsigned long addr, unsigned long len,
|
|
|
|
unsigned long prot, unsigned long flags, unsigned long fd,
|
|
|
|
unsigned long pgoff)
|
|
|
|
{
|
|
|
|
/* Make sure the shift for mmap2 is constant (12), no matter what PAGE_SIZE
|
|
|
|
we have. */
|
2018-03-11 13:34:46 +03:00
|
|
|
return ksys_mmap_pgoff(addr, len, prot, flags, fd,
|
|
|
|
pgoff >> (PAGE_SHIFT - 12));
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
asmlinkage unsigned long sys_mmap(unsigned long addr, unsigned long len,
|
|
|
|
unsigned long prot, unsigned long flags, unsigned long fd,
|
|
|
|
unsigned long offset)
|
|
|
|
{
|
|
|
|
if (!(offset & ~PAGE_MASK)) {
|
2018-03-11 13:34:46 +03:00
|
|
|
return ksys_mmap_pgoff(addr, len, prot, flags, fd,
|
2009-12-01 01:37:04 +03:00
|
|
|
offset >> PAGE_SHIFT);
|
2005-04-17 02:20:36 +04:00
|
|
|
} else {
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Fucking broken ABI */
|
|
|
|
|
|
|
|
#ifdef CONFIG_64BIT
|
|
|
|
asmlinkage long parisc_truncate64(const char __user * path,
|
|
|
|
unsigned int high, unsigned int low)
|
|
|
|
{
|
2018-03-19 19:32:11 +03:00
|
|
|
return ksys_truncate(path, (long)high << 32 | low);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
asmlinkage long parisc_ftruncate64(unsigned int fd,
|
|
|
|
unsigned int high, unsigned int low)
|
|
|
|
{
|
2018-03-11 13:34:54 +03:00
|
|
|
return ksys_ftruncate(fd, (long)high << 32 | low);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* stubs for the benefit of the syscall_table since truncate64 and truncate
|
|
|
|
* are identical on LP64 */
|
|
|
|
asmlinkage long sys_truncate64(const char __user * path, unsigned long length)
|
|
|
|
{
|
2018-03-19 19:32:11 +03:00
|
|
|
return ksys_truncate(path, length);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
asmlinkage long sys_ftruncate64(unsigned int fd, unsigned long length)
|
|
|
|
{
|
2018-03-11 13:34:54 +03:00
|
|
|
return ksys_ftruncate(fd, length);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
asmlinkage long sys_fcntl64(unsigned int fd, unsigned int cmd, unsigned long arg)
|
|
|
|
{
|
|
|
|
return sys_fcntl(fd, cmd, arg);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
|
|
|
|
asmlinkage long parisc_truncate64(const char __user * path,
|
|
|
|
unsigned int high, unsigned int low)
|
|
|
|
{
|
2018-03-19 19:32:11 +03:00
|
|
|
return ksys_truncate(path, (loff_t)high << 32 | low);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
asmlinkage long parisc_ftruncate64(unsigned int fd,
|
|
|
|
unsigned int high, unsigned int low)
|
|
|
|
{
|
|
|
|
return sys_ftruncate64(fd, (loff_t)high << 32 | low);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
asmlinkage ssize_t parisc_pread64(unsigned int fd, char __user *buf, size_t count,
|
|
|
|
unsigned int high, unsigned int low)
|
|
|
|
{
|
2018-03-19 19:38:31 +03:00
|
|
|
return ksys_pread64(fd, buf, count, (loff_t)high << 32 | low);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
asmlinkage ssize_t parisc_pwrite64(unsigned int fd, const char __user *buf,
|
|
|
|
size_t count, unsigned int high, unsigned int low)
|
|
|
|
{
|
2018-03-19 19:38:31 +03:00
|
|
|
return ksys_pwrite64(fd, buf, count, (loff_t)high << 32 | low);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
asmlinkage ssize_t parisc_readahead(int fd, unsigned int high, unsigned int low,
|
|
|
|
size_t count)
|
|
|
|
{
|
2018-03-19 19:51:36 +03:00
|
|
|
return ksys_readahead(fd, (loff_t)high << 32 | low, count);
|
2005-04-17 02:20:36 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
asmlinkage long parisc_fadvise64_64(int fd,
|
|
|
|
unsigned int high_off, unsigned int low_off,
|
|
|
|
unsigned int high_len, unsigned int low_len, int advice)
|
|
|
|
{
|
2018-03-11 13:34:45 +03:00
|
|
|
return ksys_fadvise64_64(fd, (loff_t)high_off << 32 | low_off,
|
2005-04-17 02:20:36 +04:00
|
|
|
(loff_t)high_len << 32 | low_len, advice);
|
|
|
|
}
|
|
|
|
|
2006-04-20 08:44:07 +04:00
|
|
|
asmlinkage long parisc_sync_file_range(int fd,
|
|
|
|
u32 hi_off, u32 lo_off, u32 hi_nbytes, u32 lo_nbytes,
|
|
|
|
unsigned int flags)
|
|
|
|
{
|
2018-03-11 13:34:47 +03:00
|
|
|
return ksys_sync_file_range(fd, (loff_t)hi_off << 32 | lo_off,
|
2006-04-20 08:44:07 +04:00
|
|
|
(loff_t)hi_nbytes << 32 | lo_nbytes, flags);
|
|
|
|
}
|
|
|
|
|
2013-02-20 00:23:59 +04:00
|
|
|
asmlinkage long parisc_fallocate(int fd, int mode, u32 offhi, u32 offlo,
|
|
|
|
u32 lenhi, u32 lenlo)
|
|
|
|
{
|
2018-03-19 19:46:32 +03:00
|
|
|
return ksys_fallocate(fd, mode, ((u64)offhi << 32) | offlo,
|
|
|
|
((u64)lenhi << 32) | lenlo);
|
2013-02-20 00:23:59 +04:00
|
|
|
}
|
|
|
|
|
2006-08-27 19:12:13 +04:00
|
|
|
long parisc_personality(unsigned long personality)
|
|
|
|
{
|
|
|
|
long err;
|
|
|
|
|
|
|
|
if (personality(current->personality) == PER_LINUX32
|
2012-08-02 17:33:59 +04:00
|
|
|
&& personality(personality) == PER_LINUX)
|
|
|
|
personality = (personality & ~PER_MASK) | PER_LINUX32;
|
2006-08-27 19:12:13 +04:00
|
|
|
|
|
|
|
err = sys_personality(personality);
|
2012-08-02 17:33:59 +04:00
|
|
|
if (personality(err) == PER_LINUX32)
|
|
|
|
err = (err & ~PER_MASK) | PER_LINUX;
|
2006-08-27 19:12:13 +04:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|