summaryrefslogtreecommitdiff
path: root/crypto/essiv.c
diff options
context:
space:
mode:
authorEric W. Biederman <ebiederm@xmission.com>2020-05-16 16:29:20 -0500
committerEric W. Biederman <ebiederm@xmission.com>2020-05-17 10:48:24 -0500
commitf87d1c9559164294040e58f5e3b74a162bf7c6e8 (patch)
treeec4f5055c1e068be108d1f00d7e4125d8e5a1288 /crypto/essiv.c
parent6a8b55ed4056ea5559ebe4f6a4b247f627870d4c (diff)
exec: Move would_dump into flush_old_exec
I goofed when I added mm->user_ns support to would_dump. I missed the fact that in the case of binfmt_loader, binfmt_em86, binfmt_misc, and binfmt_script bprm->file is reassigned. Which made the move of would_dump from setup_new_exec to __do_execve_file before exec_binprm incorrect as it can result in would_dump running on the script instead of the interpreter of the script. The net result is that the code stopped making unreadable interpreters undumpable. Which allows them to be ptraced and written to disk without special permissions. Oops. The move was necessary because the call in set_new_exec was after bprm->mm was no longer valid. To correct this mistake move the misplaced would_dump from __do_execve_file into flos_old_exec, before exec_mmap is called. I tested and confirmed that without this fix I can attach with gdb to a script with an unreadable interpreter, and with this fix I can not. Cc: stable@vger.kernel.org Fixes: f84df2a6f268 ("exec: Ensure mm->user_ns contains the execed files") Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Diffstat (limited to 'crypto/essiv.c')
0 files changed, 0 insertions, 0 deletions