lkml.org 
[lkml]   [2017]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode
    On Fri, May 12, 2017 at 2:06 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
    > On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote:
    >> On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote:
    >> > I'm clearly not explaining things well enough. I shouldn't say
    >> > "corruption", I should say "malicious manipulation". The methodology
    >> > of attacks against the stack are quite different from the other kinds
    >> > of attacks like use-after-free, heap overflow, etc. Being able to
    >> > exhaust the kernel stack (either due to deep recursion or unbounded
    >> > alloca())
    >>
    >> I really hope we don't have alloca() use in the kernel. Do you have
    >> evidence to support that assertion?
    >>
    >> IMHO alloca() (or similar) should not be present in any kernel code
    >> because we have a limited stack - we have kmalloc() etc for that kind
    >> of thing.
    >
    > No alloca(), but there are VLAs. Said that, the whole "what if they
    > can bugger thread_info and/or task_struct and go after set_fs() state"
    > is idiocy, of course - in that case the box is fucked, no matter what.

    Two things are at risk from stack exhaustion: thread_info (mainly
    addr_limit) when on the stack (fixed by THREAD_INFO_IN_TASK), and
    overflow into adjacent allocations (fixed by VMAP_STACK). The latter
    is fundamentally a heap overflow.

    -Kees

    --
    Kees Cook
    Pixel Security

    \
     
     \ /
      Last update: 2017-05-12 23:19    [W:4.755 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site