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
the userspace. E.g. glibc uses as large as 64kB alloca() in many
commonly used functions. 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 the userspace but
that can be done later on top when somebody finds that the new 1MB is
not suitable or even wrong for some special case applications.

Implementation wise, get rid of check_stack_guard_page and move all the
guard page specific code to expandable_stack_area which always tries to
guarantee the gap. do_anonymous_page then just calls expand_stack. Also
get rid of stack_guard_page_{start,end} and replace them with
stack_guard_area to handle stack population and /proc/<pid>/[s]maps.

This should clean up the code which is quite scattered currently
and therefore justify the change.

TODO: ia64 page fault handling calls expand_upwards explicitly for
register store. Do we need a gap there as well?

CVE-2017-1000364
Signed-off-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>