Skip to content

L
linux
Switch branch/tag
  1. 08 Jun, 2017 2 commits
    • Michal Hocko's avatar
      mm: do not collapse stack gap into THP · cc9020f7
      Michal Hocko authored 
      Oleg has noticed that khugepaged will happilly collapse stack vma (as
long as it is not an early stack - see is_vma_temporary_stack) and
it might effectively remove the stack gap area as well because a larger
part of the stack vma is usually populated. The same applies to the
page fault handler.

Fix this by checking stack_guard_area when revalidating a VMA
in hugepage_vma_revalidate.  We do not want to hook/replace
is_vma_temporary_stack() check because THP might be still useful for
stack, all we need is excluding the gap from collapsing into a THP.

Also check the to-be-created THP in do_huge_pmd_anonymous_page to
make sure it is completely outside of the gap area because we we could
create THP covering the gap area.

CVE-2017-1000364
Noticed-by: default avatarOleg Nesterov <oleg@redhat.com>
Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
[move khugepaged.c code into huge_memory.c]
Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
      cc9020f7
    • Michal Hocko's avatar
      mm: enlarge stack guard gap · b9f2a4fb
      Michal Hocko authored 
      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: default avatarMichal Hocko <mhocko@suse.com>
Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
      b9f2a4fb
  3. 31 May, 2017 1 commit
  5. 17 May, 2017 4 commits
  7. 16 May, 2017 1 commit
  9. 12 May, 2017 4 commits
  11. 08 May, 2017 18 commits
  13. 05 May, 2017 10 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7