diff options
author | Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> | 2008-04-29 00:59:17 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2008-04-29 08:06:03 -0700 |
commit | 175a06ae300188af8a61db68a78e1af44dc7d44f (patch) | |
tree | ed088932ad725985ead11fbf9e4cd7754af0dcc8 /arch/um/kernel/time.c | |
parent | ecd0fa9825a1270e31fb48bc9edcfb28918b6c51 (diff) | |
download | linux-175a06ae300188af8a61db68a78e1af44dc7d44f.tar.gz linux-175a06ae300188af8a61db68a78e1af44dc7d44f.tar.bz2 linux-175a06ae300188af8a61db68a78e1af44dc7d44f.zip |
exec: remove argv_len from struct linux_binprm
I noticed that 2.6.24.2 calculates bprm->argv_len at do_execve(). But it
doesn't update bprm->argv_len after "remove_arg_zero() +
copy_strings_kernel()" at load_script() etc.
audit_bprm() is called from search_binary_handler() and
search_binary_handler() is called from load_script() etc. Thus, I think the
condition check
if (bprm->argv_len > (audit_argv_kb << 10))
return -E2BIG;
in audit_bprm() might return wrong result when strlen(removed_arg) !=
strlen(spliced_args). Why not update bprm->argv_len at load_script() etc. ?
By the way, 2.6.25-rc3 seems to not doing the condition check. Is the field
bprm->argv_len no longer needed?
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Ollie Wild <aaw@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch/um/kernel/time.c')
0 files changed, 0 insertions, 0 deletions