diff options
author | Kees Cook <keescook@chromium.org> | 2012-12-17 16:03:20 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2012-12-17 17:15:23 -0800 |
commit | d740269867021faf4ce38a449353d2b986c34a67 (patch) | |
tree | e0476e1be1dfb6e852adbaa8fb72ecea87bdb088 /firmware/e100 | |
parent | 8d238027b87e654be552eabdf492042a34c5c300 (diff) | |
download | linux-d740269867021faf4ce38a449353d2b986c34a67.tar.gz linux-d740269867021faf4ce38a449353d2b986c34a67.tar.bz2 linux-d740269867021faf4ce38a449353d2b986c34a67.zip |
exec: use -ELOOP for max recursion depth
To avoid an explosion of request_module calls on a chain of abusive
scripts, fail maximum recursion with -ELOOP instead of -ENOEXEC. As soon
as maximum recursion depth is hit, the error will fail all the way back
up the chain, aborting immediately.
This also has the side-effect of stopping the user's shell from attempting
to reexecute the top-level file as a shell script. As seen in the
dash source:
if (cmd != path_bshell && errno == ENOEXEC) {
*argv-- = cmd;
*argv = cmd = path_bshell;
goto repeat;
}
The above logic was designed for running scripts automatically that lacked
the "#!" header, not to re-try failed recursion. On a legitimate -ENOEXEC,
things continue to behave as the shell expects.
Additionally, when tracking recursion, the binfmt handlers should not be
involved. The recursion being tracked is the depth of calls through
search_binary_handler(), so that function should be exclusively responsible
for tracking the depth.
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>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'firmware/e100')
0 files changed, 0 insertions, 0 deletions