Re: New do_mremap vulnerabitily.

[Andrea Arcangeli <andrea@suse.de>]

On Wed, Feb 18, 2004 at 05:13:56PM -0500, Chris Friesen wrote:
> Linus Torvalds wrote:
> 
> >Fixed in 2.6.3 and 2.4.25 (and, I think, vendor kernels), please upgrade
> >if you allow local shell access to untrusted users.
> 
> There is still a call to do_munmap() that does not check the return 
> code, called from move_vma(), which in turn is called in do_mremap().
> 
> Can that call ever fail and cause Bad Things to happen?

it shouldn't cause bad things, it may generate a corrupt address space
from userspace point of view (the original vma will be stil there), but
it's like if you did one more mmap, so it's only a problem if you can
drive the app to buffer overflow or something like that because of this
corrupted address space. So it's only an userspace issue with real apps,
and with real apps the only thing that can make munamp fail is an oom
which is near to impossible for you to oom the app exactly in this
do_munmap call, the by far highest probability is that the first oom
will happen in the page faults, not in the syscalls.

> If we know that its never going to fail, it might be useful to have a 
> comment explaining it so we don't open up more exploits in the future.

the whole code needs a revamp for example for when the pagetables cannot
be allocated and the merging isn't retired (similar problem to the
do_munmap you mentioned above and there are other issues like that),
mremap simply isn't retiring correctly in presence of oom errors, that's
only an userspace issue, no way to exploit the kernel with that, we've
to fix it for 2.6 to provide perfect retirement from oom (basically only
a pratical matter with full overcommit but anyways). For 2.4 where the
thing will go in production the next day, going with the bandaid from
Solar was the simplest and in turn safest solution without risk of
regression.