diff options
author | Oleg Nesterov <oleg@redhat.com> | 2010-11-30 20:55:34 +0100 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2010-11-30 17:56:37 -0800 |
commit | 3c77f845722158206a7209c45ccddc264d19319c (patch) | |
tree | 9eace97a8b88eb68b7d5d3127041b14c202421ae /README | |
parent | 37a09f07459753e7c98d4e21f1c61e8756923f81 (diff) | |
download | op-kernel-dev-3c77f845722158206a7209c45ccddc264d19319c.zip op-kernel-dev-3c77f845722158206a7209c45ccddc264d19319c.tar.gz |
exec: make argv/envp memory visible to oom-killer
Brad Spengler published a local memory-allocation DoS that
evades the OOM-killer (though not the virtual memory RLIMIT):
http://www.grsecurity.net/~spender/64bit_dos.c
execve()->copy_strings() can allocate a lot of memory, but
this is not visible to oom-killer, nobody can see the nascent
bprm->mm and take it into account.
With this patch get_arg_page() increments current's MM_ANONPAGES
counter every time we allocate the new page for argv/envp. When
do_execve() succeds or fails, we change this counter back.
Technically this is not 100% correct, we can't know if the new
page is swapped out and turn MM_ANONPAGES into MM_SWAPENTS, but
I don't think this really matters and everything becomes correct
once exec changes ->mm or fails.
Reported-by: Brad Spengler <spender@grsecurity.net>
Reviewed-and-discussed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions