PR/60657 CVS commit: [netbsd-10] src/sys

["Martin Husemann" <martin%netbsd.org@localhost>]

The following reply was made to PR kern/60657; it has been noted by GNATS.

From: "Martin Husemann" <martin%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/60657 CVS commit: [netbsd-10] src/sys
Date: Sat, 24 Oct 2026 10:39:52 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sat Oct 24 10:39:52 UTC 2026
 
 Modified Files:
 	src/sys/compat/netbsd32 [netbsd-10]: netbsd32_signal.c
 	src/sys/kern [netbsd-10]: exec_script.c exec_subr.c kern_exec.c
 	    kern_fork.c
 
 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #541):
 
 	sys/compat/netbsd32/netbsd32_signal.c: revision 1.57
 	sys/kern/kern_fork.c: revision 1.235
 	sys/kern/exec_subr.c: revision 1.93 (via patch)
 	sys/kern/kern_exec.c: revision 1.534 (via patch)
 	sys/kern/kern_exec.c: revision 1.535 (via patch)
 	sys/kern/exec_script.c: revision 1.86 (via patch)
 
 exec: Free struct exec_package::ep_emul_arg in more error paths.
 
 We should really formalize the destruction path for these temporary
 exec data structures; these error branches are all tangled messes of
 spaghetti.
 
 PR kern/60657: panic: kernel diagnostic assertion "epp->ep_emul_arg
 == NULL" failed: file
 "/home/riastradh/netbsd/current/src/sys/kern/kern_exec.c", line 535
 
 Test case forthcoming (it would panic the testbed) as part of
 
 PR kern/60653: posix_spawn(3) causes incorrect stack base information
 which is how I stumbled upon this.
 
 Test various methods of getting the process's stack base and size.
 And test the effect of fork, vfork, failed execve, and posix_spawn on
 them.
 
 PR kern/60653: posix_spawn(3) causes incorrect stack base information
 
 t_signal_and_sp: Link against libpthread unconditionally now.
 
 Required by new test cases added for:
 PR kern/60653: posix_spawn(3) causes incorrect stack base information
 
 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, however, broke the stack base returned by getcontext()
 in programs that have tried to exec other programs and failed in
 various ways.  And made the later introduction of posix_spawn break
 the stack base in the _parent_.
 
 To fix this, we set p_stackbase -- under p_lock, to avoid racing with
 sysctl_doeproc in another thread -- only in execve_runproc once we're
 committed to the exec, but before copyoutargs -> es_copyargs =
 elf_copyargs -> elf_populate_auxv needs to read it.  (That said,
 elf_populate_auxv(..., pack, ...) could just use pack->es_minsaddr
 directly anyway, and then we wouldn't have that ordering constraint.)
 
 PR kern/60653: posix_spawn(3) causes incorrect stack base information
 
 fork(2), vfork(2): Copy the parent's stack base pointer to the child.
 
 Don't just leak whatever random stack pointer some recycled struct
 proc had!
 
 TBD: Move p_stackbase in struct proc so this is covered by the memcpy
 above, in a separate commit so we can pull this one up without any
 change to the layout of struct proc.
 PR kern/60653: posix_spawn(3) causes incorrect stack base information
 
 compat32: Advertise true stack base to getcontext(2).
 Needs adjustment for PaX ASLR.
 
 This was missed as part of:
 Module Name:    src
 Committed By:   christos
 Date:           Wed Dec 26 22:11:54 UTC 2007
 Add PaX ASLR (Address Space Layout Randomization) [from elad and myself]
 https://mail-index.NetBSD.org/source-changes/2007/12/26/msg195243.html
 
 PR kern/60877: t_signal_and_sp test failure with i386 userland on amd64
 kernel
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.53.4.1 -r1.53.4.2 src/sys/compat/netbsd32/netbsd32_signal.c
 cvs rdiff -u -r1.83 -r1.83.14.1 src/sys/kern/exec_script.c
 cvs rdiff -u -r1.84.20.2 -r1.84.20.3 src/sys/kern/exec_subr.c
 cvs rdiff -u -r1.518.4.4 -r1.518.4.5 src/sys/kern/kern_exec.c
 cvs rdiff -u -r1.229 -r1.229.4.1 src/sys/kern/kern_fork.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.