summaryrefslogtreecommitdiffstats
path: root/mm
diff options
context:
space:
mode:
authorKees Cook <keescook@chromium.org>2012-12-20 15:05:16 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2012-12-20 17:40:19 -0800
commitb66c5984017533316fd1951770302649baf1aa33 (patch)
tree78d1e5fc82a057c62699734602c8e5f7ca86b7a2 /mm
parent9f9c9cbb60576a1518d0bf93fb8e499cffccf377 (diff)
downloadlinux-b66c5984017533316fd1951770302649baf1aa33.tar.bz2
exec: do not leave bprm->interp on stack
If a series of scripts are executed, each triggering module loading via unprintable bytes in the script header, kernel stack contents can leak into the command line. Normally execution of binfmt_script and binfmt_misc happens recursively. However, when modules are enabled, and unprintable bytes exist in the bprm->buf, execution will restart after attempting to load matching binfmt modules. Unfortunately, the logic in binfmt_script and binfmt_misc does not expect to get restarted. They leave bprm->interp pointing to their local stack. This means on restart bprm->interp is left pointing into unused stack memory which can then be copied into the userspace argv areas. After additional study, it seems that both recursion and restart remains the desirable way to handle exec with scripts, misc, and modules. As such, we need to protect the changes to interp. This changes the logic to require allocation for any changes to the bprm->interp. To avoid adding a new kmalloc to every exec, the default value is left as-is. Only when passing through binfmt_script or binfmt_misc does an allocation take place. For a proof of concept, see DoTest.sh from: http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/ Signed-off-by: Kees Cook <keescook@chromium.org> Cc: halfdog <me@halfdog.net> Cc: P J P <ppandit@redhat.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions