On Thu, Mar 21, 2024 at 12:52:16PM -0700, Max Filippov wrote: > 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. Ah, perfect! Thanks for this. > 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<--- Does musl have something like the LD_SHOW_AUXV env variable. With glibc, I usually explore auxv like so: $ LD_SHOW_AUXV=1 uname -a | grep EXECFN AT_EXECFN: /usr/bin/uname > > 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! -- Kees Cook
