Re: kern/60653 (posix_spawn(3) causes incorrect stack base information)

[riastradh%NetBSD.org@localhost]

Synopsis: posix_spawn(3) causes incorrect stack base information

State-Changed-From-To: open->feedback
State-Changed-By: riastradh%NetBSD.org@localhost
State-Changed-When: Wed, 26 Aug 2026 22:39:00 +0000
State-Changed-Why:
Can you please try the attached patch?

# HG changeset patch
# User Taylor R Campbell <riastradh%NetBSD.org@localhost>
# Date 1787783882 0
#      Wed Aug 26 22:38:02 2026 +0000
# Branch trunk
# Node ID 58c75a303ca0a98800bf14fa4c16c33435dc6e65
# Parent  4fbd288ac1da9e7d9592ddecf04f7513e244152f
# EXP-Topic riastradh-pr60653-execstackbase
WIP: execve(2): Set p_stackbase in execve_runproc, not execve_loadvm.

execve_loadvm must not have side effects on the running process for
two reasons:

1. If execve(2) fails, it has to be able to back out and return to
   the calling process.  For example, the shell will execute the
   first of a series of candidate paths that works when it searches
   $PATH, and if one fails, it has to be able to move on to try the
   next.

2. The caller may be the _parent_ process -- this is the case when
   we're in posix_spawn.

Instead, it must be set in execve_runproc, after we're committed to
the exec and can't back out -- and we're definitely operating on the
process that is executing a new image, not on its parent!

p_stackbase and its assignment in exec_setup_stack, a subroutine of
execve_loadvm, were introduced with the PaX ASLR changes back in 2007
in order to pass the true stack base via AT_STACKBASE in the ELF
auxv, and in order to have getcontext() return the true stack base,
in the face of address space layout randomization.  (This change
probably also broke the stack base returned by getcontext() in
programs that have tried to exec other programs and failed under
certain obscure modes of failure .)

PR kern/60653: posix_spawn(3) causes incorrect stack base information

diff -r 4fbd288ac1da -r 58c75a303ca0 sys/compat/linux32/arch/aarch64/linux32_exec_machdep.c
--- a/sys/compat/linux32/arch/aarch64/linux32_exec_machdep.c	Mon Aug 10 13:36:10 2026 +0000
+++ b/sys/compat/linux32/arch/aarch64/linux32_exec_machdep.c	Wed Aug 26 22:38:02 2026 +0000
@@ -107,8 +107,6 @@ linux32_exec_setup_stack(struct lwp *l, 
 	epp->ep_maxsaddr =
 	    (vaddr_t)STACK_GROW(epp->ep_minsaddr, max_stack_size);
 
-	l->l_proc->p_stackbase = epp->ep_minsaddr;
-
 	/*
 	 * set up commands for stack.  note that this takes *two*, one to
 	 * map the part of the stack which we can access, and one to map
diff -r 4fbd288ac1da -r 58c75a303ca0 sys/kern/exec_subr.c
--- a/sys/kern/exec_subr.c	Mon Aug 10 13:36:10 2026 +0000
+++ b/sys/kern/exec_subr.c	Wed Aug 26 22:38:02 2026 +0000
@@ -421,8 +421,6 @@ exec_setup_stack(struct lwp *l, struct e
 	epp->ep_ssize = MIN(l->l_proc->p_rlimit[RLIMIT_STACK].rlim_cur,
 	    max_stack_size);
 
-	l->l_proc->p_stackbase = epp->ep_minsaddr;
-
 	epp->ep_maxsaddr = (vaddr_t)STACK_GROW(epp->ep_minsaddr,
 	    max_stack_size);
 
diff -r 4fbd288ac1da -r 58c75a303ca0 sys/kern/kern_exec.c
--- a/sys/kern/kern_exec.c	Mon Aug 10 13:36:10 2026 +0000
+++ b/sys/kern/kern_exec.c	Wed Aug 26 22:38:02 2026 +0000
@@ -1281,6 +1281,7 @@ execve_runproc(struct lwp *l, struct exe
 	l->l_ctxlink = NULL;	/* reset ucontext link */
 	p->p_acflag &= ~AFORK;
 	p->p_flag |= PK_EXEC;
+	p->p_stackbase = epp->ep_minsaddr;
 	mutex_exit(p->p_lock);
 
 	error = credexec(l, data);