lkml.org 
[lkml]   [2014]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] Detaching mounts on unlink for 3.15-rc1
    On Wed, Apr 09, 2014 at 06:53:23PM +0100, Al Viro wrote:

    > For starters, put that ext4 on top of dm-raid or dm-multipath. That alone
    > will very likely push you over the top.
    >
    > Keep in mind, BTW, that you do not have full 8K to play with - there's
    > struct thread_info that should not be stepped upon. Not particulary large
    > (IIRC, restart_block is the largest piece in amd64 one), but it eats about
    > 100 bytes.
    >
    > I'd probably use renameat(2) in testing - i.e. trigger the shite when
    > resolving a deeply nested symlink in renameat() arguments. That brings
    > extra struct nameidata into the game, i.e. extra 152 bytes chewed off the
    > stack.

    Come to think of that, some extra nastiness could be had by mixing it with
    execve(). You can have up to 4 levels of #! resolution there, each eating
    up at least 128 bytes (more, actually). Compiler _might_ turn that
    tail call of search_binary_handler() into a jump, but it's not guaranteed
    at all.

    FWIW, it probably makes sense to turn load_script() into
    static int load_script(struct linux_binprm *bprm)
    {
    int err = __load_script(bprm);
    if (err)
    return err;
    return search_binary_handler(bprm);
    }

    regardless of that issue; we don't need interp[] after the call of
    open_exec(), so it makes sense to reduce the footprint in mutual
    recursion loop.

    For extra pain, consider s/ext4/xfs/, possibly with iscsi thrown under the
    bus^Wdm-multipath.

    The thing is, we are already too close to stack overflow limit. Adding
    several kilobytes more is not survivable, and since you are taking
    somebody in a userns DoSing the system into consideration, you can't
    say "it takes malicious root to set up, so it's not serious" - the
    DoS you mentioned requires the same thing...

    BTW, another thing to test would be this:
    mount nfs on /mnt
    mount a filesystem on /mnt/path that can be invalidated
    cd to /mnt/path/foo
    bind /mnt on /mnt/path/foo/bar
    shoot /mnt/path (on server)
    stat bar/path/foo
    That should rip the fs you are in out of the tree; it should work, but
    it's definitely a case worth testing.


    \
     
     \ /
      Last update: 2014-04-09 21:21    [W:4.022 / U:0.316 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site