On Thu, Mar 21, 2024 at 10:05 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > On Wed, Mar 20, 2024 at 11:26:07AM -0700, Max Filippov wrote: > > In NUMMU kernel the value of linux_binprm::p is the offset inside the > > temporary program arguments array maintained in separate pages in the > > linux_binprm::page. linux_binprm::exec being a copy of linux_binprm::p > > thus must be adjusted when that array is copied to the user stack. > > Without that adjustment the value passed by the NOMMU kernel to the ELF > > program in the AT_EXECFN entry of the aux array doesn't make any sense > > and it may break programs that try to access memory pointed to by that > > entry. > > > > Adjust linux_binprm::exec before the successful return from the > > transfer_args_to_stack(). > > What's the best way to test this? (Is there a qemu setup I can use to > see the before/after of AT_EXECFN?) I put a readme with the steps to build such system here: http://jcmvbkbc.org/~dumb/tmp/202403211236/README it uses a prebuilt rootfs image and a 6.8 kernel branch with two patches on top of it: one adds a dts and a defconfig and the other is this fix. The rootfs boots successfully with this fix, but panics if this fix is removed. The easiest way to actually see the AT_EXECFN is, I guess, to do something like that: ---8<--- diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index fefc642541cb..22d34272a570 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -659,6 +659,7 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm, NEW_AUX_ENT(AT_EGID, (elf_addr_t) from_kgid_munged(cred->user_ns, cred->egid)); NEW_AUX_ENT(AT_SECURE, bprm->secureexec); NEW_AUX_ENT(AT_EXECFN, bprm->exec); + pr_info("%s: AT_EXECFN = %#lx\n", __func__, bprm->exec); #ifdef ARCH_DLINFO nr = 0; ---8<--- > How did you encounter the problem? I'm doing xtensa FDPIC port of musl libc and this issue popped up when I began testing it on qemu-system-xtensa with the real linux kernel. Related post to the musl ML: https://www.openwall.com/lists/musl/2024/03/20/2 -- Thanks. -- Max
