Messages in this thread | | | Date | Wed, 9 Apr 2014 19:28:32 +0100 | From | Al Viro <> | Subject | Re: [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.
| |