aboutsummaryrefslogtreecommitdiff
path: root/scripts/gdb
diff options
context:
space:
mode:
authorEric W. Biederman <[email protected]>2023-09-28 20:24:29 -0700
committerKees Cook <[email protected]>2023-09-29 09:54:27 -0700
commit585a018627b4d7ed37387211f667916840b5c5ea (patch)
treed0dc215e7a35412983de17491e07ffb17b5c023d /scripts/gdb
parentff7a65492c4c88010491ca0995a7e072d2c01879 (diff)
binfmt_elf: Support segments with 0 filesz and misaligned starts
Implement a helper elf_load() that wraps elf_map() and performs all of the necessary work to ensure that when "memsz > filesz" the bytes described by "memsz > filesz" are zeroed. An outstanding issue is if the first segment has filesz 0, and has a randomized location. But that is the same as today. In this change I replaced an open coded padzero() that did not clear all of the way to the end of the page, with padzero() that does. I also stopped checking the return of padzero() as there is at least one known case where testing for failure is the wrong thing to do. It looks like binfmt_elf_fdpic may have the proper set of tests for when error handling can be safely completed. I found a couple of commits in the old history https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git, that look very interesting in understanding this code. commit 39b56d902bf3 ("[PATCH] binfmt_elf: clearing bss may fail") commit c6e2227e4a3e ("[SPARC64]: Missing user access return value checks in fs/binfmt_elf.c and fs/compat.c") commit 5bf3be033f50 ("v2.4.10.1 -> v2.4.10.2") Looking at commit 39b56d902bf3 ("[PATCH] binfmt_elf: clearing bss may fail"): > commit 39b56d902bf35241e7cba6cc30b828ed937175ad > Author: Pavel Machek <[email protected]> > Date: Wed Feb 9 22:40:30 2005 -0800 > > [PATCH] binfmt_elf: clearing bss may fail > > So we discover that Borland's Kylix application builder emits weird elf > files which describe a non-writeable bss segment. > > So remove the clear_user() check at the place where we zero out the bss. I > don't _think_ there are any security implications here (plus we've never > checked that clear_user() return value, so whoops if it is a problem). > > Signed-off-by: Pavel Machek <[email protected]> > Signed-off-by: Andrew Morton <[email protected]> > Signed-off-by: Linus Torvalds <[email protected]> It seems pretty clear that binfmt_elf_fdpic with skipping clear_user() for non-writable segments and otherwise calling clear_user(), aka padzero(), and checking it's return code is the right thing to do. I just skipped the error checking as that avoids breaking things. And notably, it looks like Borland's Kylix died in 2005 so it might be safe to just consider read-only segments with memsz > filesz an error. Reported-by: Sebastian Ott <[email protected]> Reported-by: Thomas Weißschuh <[email protected]> Closes: https://lkml.kernel.org/r/[email protected] Signed-off-by: "Eric W. Biederman" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Pedro Falcato <[email protected]> Signed-off-by: Sebastian Ott <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]>
Diffstat (limited to 'scripts/gdb')
0 files changed, 0 insertions, 0 deletions