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>

Pull ARM SoC fixes from Olof Johansson:
 "Stream of fixes has slowed down, only a few this week:

   - Some DT fixes for Allwinner platforms, and addition of a clock to
     the R_CCU clock controller that had been missed.

   - A couple of small DT fixes for am335x-sl50"

* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  arm64: allwinner: a64: Add PLL_PERIPH0 clock to the R_CCU
  ARM: sunxi: h3-h5: Add PLL_PERIPH0 clock to the R_CCU
  ARM: dts: am335x-sl50: Fix cannot claim requested pins for spi0
  ARM: dts: am335x-sl50: Fix card detect pin for mmc1
  arm64: allwinner: h5: Remove syslink to shared DTSI
  ARM: sunxi: h3/h5: fix the compatible of R_CCU

Allwinner fixes for 4.12

A few fixes around the PRCM support that got in 4.12 with a wrong
compatible, and a missing clock in the binding.

* tag 'sunxi-fixes-for-4.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
  arm64: allwinner: a64: Add PLL_PERIPH0 clock to the R_CCU
  ARM: sunxi: h3-h5: Add PLL_PERIPH0 clock to the R_CCU
  arm64: allwinner: h5: Remove syslink to shared DTSI
  ARM: sunxi: h3/h5: fix the compatible of R_CCU

Signed-off-by: Olof Johansson <olof@lixom.net>

Two fixes for am335x-sl50 to fix a boot time error
for claiming SPI pins, and to fix a SDIO card detect
pin for production version of the device.

* tag 'omap-for-v4.12/fixes-sl50' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: dts: am335x-sl50: Fix cannot claim requested pins for spi0
  ARM: dts: am335x-sl50: Fix card detect pin for mmc1

Signed-off-by: Olof Johansson <olof@lixom.net>

Pull virtio bugfix from Michael Tsirkin:
 "It turns out balloon does not handle IOMMUs correctly. We should fix
  that at some point, for now let's just disable this configuration"

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  virtio_balloon: disable VIOMMU support

Pull i2c fixes from Wolfram Sang:
 "Two driver bugfixes"

* 'i2c/for-current-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: ismt: fix wrong device address when unmap the data buffer
  i2c: rcar: use correct length when unmapping DMA

Pull MIPS fixes from Ralf Baechle:

 - Three highmem fixes:
    + Fixed mapping initialization
    + Adjust the pkmap location
    + Ensure we use at most one page for PTEs

 - Fix makefile dependencies for .its targets to depend on vmlinux

 - Fix reversed condition in BNEZC and JIALC software branch emulation

 - Only flush initialized flush_insn_slot to avoid NULL pointer
   dereference

 - perf: Remove incorrect odd/even counter handling for I6400

 - ftrace: Fix init functions tracing

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: .its targets depend on vmlinux
  MIPS: Fix bnezc/jialc return address calculation
  MIPS: kprobes: flush_insn_slot should flush only if probe initialised
  MIPS: ftrace: fix init functions tracing
  MIPS: mm: adjust PKMAP location
  MIPS: highmem: ensure that we don't use more than one page for PTEs
  MIPS: mm: fixed mappings: correct initialisation
  MIPS: perf: Remove incorrect odd/even counter handling for I6400

virtio balloon bypasses the DMA API entirely so does not support the
VIOMMU right now.  It's not clear we need that support, for now let's
just make sure we don't pretend to support it.

Cc: stable@vger.kernel.org
Cc: Wei Wang <wei.w.wang@intel.com>
Fixes: 1a937693993f ("virtio: new feature to detect IOMMU device quirk")
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>

Pull x86 fixes from Thomas Gleixner:
 "Two fixlets for x86:

   - Handle WARN_ONs proper with the new UD based WARN implementation

   - Disable 1G mappings when 2M mappings are disabled by kmemleak or
     debug_pagealloc. Otherwise 1G mappings might still be used,
     confusing the debug mechanisms"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mm: Disable 1GB direct mappings when disabling 2MB mappings
  x86/debug: Handle early WARN_ONs proper