NetBSD Problem Report #60653
From wiz@netbsd.org Wed Aug 26 20:08:07 2026
Return-Path: <wiz@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits)
client-signature RSA-PSS (2048 bits))
(Client CN "mail.netbsd.org", Issuer "YR2" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id AD01A1A923B
for <gnats-bugs@gnats.NetBSD.org>; Wed, 26 Aug 2026 20:08:07 +0000 (UTC)
Message-Id: <20260826200807.33A6D84CED@mail.netbsd.org>
Date: Wed, 26 Aug 2026 20:08:07 +0000 (UTC)
From: wiz@NetBSD.org
Reply-To: wiz@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: posix_spawn(3) causes incorrect stack base information
X-Send-Pr-Version: 3.95
X-From4GNATS: "wiz@NetBSD.org via gnats" <gnats-admin@NetBSD.org>
>Number: 60653
>Notify-List: riastradh@NetBSD.org
>Category: kern
>Synopsis: posix_spawn(3) causes incorrect stack base information
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: kern-bug-people
>State: pending-pullups
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Aug 26 20:10:01 +0000 2026
>Closed-Date:
>Last-Modified: Sat Oct 24 11:10:01 +0000 2026
>Originator: Thomas Klausner
>Release: NetBSD 11.99.7
>Organization:
>Environment:
Architecture: x86_64
Machine: amd64
>Description:
Trying to track down a problem in webkit(-gtk)'s garbage collector, I had to find out
that the problem is not caused by webkit, but by posix_spawn.
webkit wants to walk its stack so it can garbage collect objects, but it regularly,
if randomly, falls into unmapped regions while doing so.
The visible problem is that after posix_spawn (but not after fork+exec), the stack
base address reported by the standard methods is incorrect. Even worse, it's not
only incorrect for the spawned process, but also for the parent process.
>How-To-Repeat:
Save the following program as posix_spawn_stack_bug.c and compile it:
cc -Wall -o posix_spawn_stack_bug posix_spawn_stack_bug.c -lpthread
Then run it:
./posix_spawn_stack_bug
#include <sys/exec.h>
#include <sys/exec_elf.h>
#include <sys/wait.h>
#include <dlfcn.h>
#include <err.h>
#include <errno.h>
#include <inttypes.h>
#include <pthread.h>
#include <spawn.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <ucontext.h>
#include <unistd.h>
extern char **environ;
extern struct ps_strings *__ps_strings;
/* how many children to fork */
#define NFORK 2
/* how many children to posix_spawn */
#define NSPAWN 2
/*
* Kernel's p_stackbase, as handed back by getcontext(2), see
* pthread__initmainstack() in src/lib/libpthread/pthread.c
*/
static uintptr_t
getcontext_stackbase(void)
{
ucontext_t uc;
if (getcontext(&uc) == -1)
err(1, "getcontext");
return (uintptr_t)uc.uc_stack.ss_sp;
}
/*
* AT_STACKBASE from the ELF auxiliary vector, see
* pthread__initmainstack() in src/lib/libpthread/pthread.c
*/
static uintptr_t
auxv_stackbase(void)
{
const AuxInfo *aux;
for (aux = _dlauxinfo(); aux != NULL && aux->a_type != AT_NULL; ++aux)
if (aux->a_type == AT_STACKBASE)
return (uintptr_t)aux->a_v;
return 0;
}
/* struct ps_strings is the first thing put on the stack, see the
* comment starting at line 103 in /usr/include/sys/exec.h, so the top
* of the stack is its address + its size.
*/
static uintptr_t
psstrings_stackbase(void)
{
if (__ps_strings == NULL)
return 0;
return (uintptr_t)__ps_strings + sizeof(struct ps_strings);
}
/* Stack bottom and top as reported by libpthread. */
static void
pthread_main_stack(uintptr_t *lo, uintptr_t *hi)
{
pthread_attr_t attr;
void *base;
size_t size;
*lo = *hi = 0;
if (pthread_getattr_np(pthread_self(), &attr) != 0)
return;
if (pthread_attr_getstack(&attr, &base, &size) != 0)
return;
pthread_attr_destroy(&attr);
*lo = (uintptr_t)base;
*hi = (uintptr_t)base + size;
}
/*
* Compare stack information retrieved in different ways
*/
static int
compare_stackdata(const char *who)
{
uintptr_t getcontext_stack = getcontext_stackbase();
uintptr_t auxv_stack = auxv_stackbase();
uintptr_t psstrings_stack = psstrings_stackbase();
uintptr_t lo, hi;
pthread_main_stack(&lo, &hi);
printf("%s pid=%d\n", who, (int)getpid());
printf(" real stack top (ps_strings) = %#lx\n", psstrings_stack);
printf(" AT_STACKBASE = %#lx%s\n", auxv_stack, auxv_stack == psstrings_stack ? "" : " <-- WRONG");
printf(" p_stackbase (getcontext) = %#lx%s\n", getcontext_stack, getcontext_stack == psstrings_stack ? "" : " <-- WRONG");
printf(" pthread main stack = %#lx .. %#lx%s\n", lo, hi, hi == psstrings_stack ? "" : " <-- WRONG");
if (auxv_stack != psstrings_stack) {
long delta = (long)auxv_stack - (long)psstrings_stack;
printf(" => off by %+ld bytes (%+ld kiB); the reported stack %s the mapping\n\n", delta, delta / 1024, delta > 0 ? "runs past the end of" : "does not reach");
return 1;
}
printf("\n");
return 0;
}
static int
run_child(char *self, char *how, int use_spawn)
{
char *argv[3];
pid_t pid;
int status, error;
argv[0] = self;
argv[1] = how;
argv[2] = NULL;
if (use_spawn) {
error = posix_spawn(&pid, self, NULL, NULL, argv, environ);
if (error != 0) {
errno = error;
err(1, how);
}
} else {
pid = fork();
if (pid == -1)
err(1, how);
if (pid == 0) {
execve(self, argv, environ);
_exit(1);
}
}
if (waitpid(pid, &status, 0) == -1)
err(1, "waitpid");
return WIFEXITED(status) ? WEXITSTATUS(status) : -1;
}
int
main(int argc, char **argv)
{
uintptr_t before, after;
int bad = 0, i;
if (argc > 1)
return compare_stackdata(argv[1]);
compare_stackdata("parent");
before = getcontext_stackbase();
printf("\n");
printf("--- fork + execve ---\n");
for (i = 0; i < NFORK; i++)
bad += run_child(argv[0], "fork+exec", 0);
printf("\n");
printf("--- posix_spawn ---\n");
for (i = 0; i < NSPAWN; i++)
bad += run_child(argv[0], "posix_spawn", 1);
printf("\n");
compare_stackdata("parent after spawn");
after = getcontext_stackbase();
if (after != before) {
printf("\nparent p_stackbase changed after spawns: %#lx -> %#lx\n", before, after);
bad++;
}
return bad != 0;
}
>Fix:
>Release-Note:
>Audit-Trail:
From: Thomas Klausner <wiz@netbsd.org>
To: NetBSD bugtracking <gnats-bugs@netbsd.org>
Cc:
Subject: Re: kern/60653: posix_spawn(3) causes incorrect stack base
information
Date: Wed, 26 Aug 2026 22:15:14 +0200
Just in case, here is the output from a NetBSD 10 system, showing it's
a long-standing problem (it's still there in 11.99.7):
# ./posix_spawn_stack_bug
parent pid=27310
real stack top (ps_strings) = 0x7f7fff0fb000
AT_STACKBASE = 0x7f7fff0fb000
p_stackbase (getcontext) = 0x7f7fff0fb000
pthread main stack = 0x7f7ffecfb000 .. 0x7f7fff0fb000
--- fork + execve ---
fork+exec pid=2245
real stack top (ps_strings) = 0x7f7fffe28000
AT_STACKBASE = 0x7f7fffe28000
p_stackbase (getcontext) = 0x7f7fffe28000
pthread main stack = 0x7f7fffa28000 .. 0x7f7fffe28000
fork+exec pid=19353
real stack top (ps_strings) = 0x7f7fffa23000
AT_STACKBASE = 0x7f7fffa23000
p_stackbase (getcontext) = 0x7f7fffa23000
pthread main stack = 0x7f7fff623000 .. 0x7f7fffa23000
--- posix_spawn ---
posix_spawn pid=25804
real stack top (ps_strings) = 0x7f7fff042000
AT_STACKBASE = 0x7f7fffa23000 <-- WRONG
p_stackbase (getcontext) = 0x7f7fffa23000 <-- WRONG
pthread main stack = 0x7f7fff623000 .. 0x7f7fffa23000 <-- WRONG
=> off by +10358784 bytes (+10116 kiB); the reported stack runs past the end of the mapping
posix_spawn pid=17587
real stack top (ps_strings) = 0x7f7fff252000
AT_STACKBASE = 0x7f7fffa23000 <-- WRONG
p_stackbase (getcontext) = 0x7f7fffa23000 <-- WRONG
pthread main stack = 0x7f7fff623000 .. 0x7f7fffa23000 <-- WRONG
=> off by +8196096 bytes (+8004 kiB); the reported stack runs past the end of the mapping
parent after spawn pid=27310
real stack top (ps_strings) = 0x7f7fff0fb000
AT_STACKBASE = 0x7f7fff0fb000
p_stackbase (getcontext) = 0x7f7fff252000 <-- WRONG
pthread main stack = 0x7f7ffecfb000 .. 0x7f7fff0fb000
parent p_stackbase changed after spawns: 0x7f7fff0fb000 -> 0x7f7fff252000
Thomas
State-Changed-From-To: open->feedback
State-Changed-By: riastradh@NetBSD.org
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>
# 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);
From: Thomas Klausner <wiz@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/60653 (posix_spawn(3) causes incorrect stack base
information)
Date: Thu, 27 Aug 2026 11:23:17 +0200
Thank you, with the patch the output looks as it should be:
parent pid=19700
real stack top (ps_strings) = 0x7f7fff6d3000
AT_STACKBASE = 0x7f7fff6d3000
p_stackbase (getcontext) = 0x7f7fff6d3000
pthread main stack = 0x7f7fff2d3000 .. 0x7f7fff6d3000
--- fork + execve ---
fork+exec pid=19686
real stack top (ps_strings) = 0x7f7fff470000
AT_STACKBASE = 0x7f7fff470000
p_stackbase (getcontext) = 0x7f7fff470000
pthread main stack = 0x7f7fff070000 .. 0x7f7fff470000
fork+exec pid=17914
real stack top (ps_strings) = 0x7f7fff4d2000
AT_STACKBASE = 0x7f7fff4d2000
p_stackbase (getcontext) = 0x7f7fff4d2000
pthread main stack = 0x7f7fff0d2000 .. 0x7f7fff4d2000
--- posix_spawn ---
posix_spawn pid=20477
real stack top (ps_strings) = 0x7f7fff602000
AT_STACKBASE = 0x7f7fff602000
p_stackbase (getcontext) = 0x7f7fff602000
pthread main stack = 0x7f7fff202000 .. 0x7f7fff602000
posix_spawn pid=19487
real stack top (ps_strings) = 0x7f7fffa07000
AT_STACKBASE = 0x7f7fffa07000
p_stackbase (getcontext) = 0x7f7fffa07000
pthread main stack = 0x7f7fff607000 .. 0x7f7fffa07000
parent after spawn pid=19700
real stack top (ps_strings) = 0x7f7fff6d3000
AT_STACKBASE = 0x7f7fff6d3000
p_stackbase (getcontext) = 0x7f7fff6d3000
pthread main stack = 0x7f7fff2d3000 .. 0x7f7fff6d3000
Thomas
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60653 CVS commit: src/sys/kern
Date: Fri, 28 Aug 2026 06:33:50 +0000
Module Name: src
Committed By: riastradh
Date: Fri Aug 28 06:33:50 UTC 2026
Modified Files:
src/sys/kern: exec_script.c kern_exec.c
Log Message:
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.
To generate a diff of this commit:
cvs rdiff -u -r1.85 -r1.86 src/sys/kern/exec_script.c
cvs rdiff -u -r1.533 -r1.534 src/sys/kern/kern_exec.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60653 CVS commit: src
Date: Fri, 28 Aug 2026 06:35:26 +0000
Module Name: src
Committed By: riastradh
Date: Fri Aug 28 06:35:26 UTC 2026
Modified Files:
src/distrib/sets/lists/debug: mi
src/distrib/sets/lists/tests: mi
src/tests/kernel: Makefile t_signal_and_sp.c
Added Files:
src/tests/kernel: getstack.c getstack.h h_getstack.c
Log Message:
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
To generate a diff of this commit:
cvs rdiff -u -r1.517 -r1.518 src/distrib/sets/lists/debug/mi
cvs rdiff -u -r1.1428 -r1.1429 src/distrib/sets/lists/tests/mi
cvs rdiff -u -r1.98 -r1.99 src/tests/kernel/Makefile
cvs rdiff -u -r0 -r1.1 src/tests/kernel/getstack.c \
src/tests/kernel/getstack.h src/tests/kernel/h_getstack.c
cvs rdiff -u -r1.21 -r1.22 src/tests/kernel/t_signal_and_sp.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60653 CVS commit: src/tests/kernel
Date: Fri, 28 Aug 2026 11:59:17 +0000
Module Name: src
Committed By: riastradh
Date: Fri Aug 28 11:59:16 UTC 2026
Modified Files:
src/tests/kernel: Makefile
Log Message:
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
To generate a diff of this commit:
cvs rdiff -u -r1.99 -r1.100 src/tests/kernel/Makefile
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60653 CVS commit: src
Date: Fri, 28 Aug 2026 12:02:16 +0000
Module Name: src
Committed By: riastradh
Date: Fri Aug 28 12:02:16 UTC 2026
Modified Files:
src/sys/compat/linux32/arch/aarch64: linux32_exec_machdep.c
src/sys/kern: exec_subr.c kern_exec.c
src/tests/kernel: t_signal_and_sp.c
Log Message:
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
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 \
src/sys/compat/linux32/arch/aarch64/linux32_exec_machdep.c
cvs rdiff -u -r1.92 -r1.93 src/sys/kern/exec_subr.c
cvs rdiff -u -r1.534 -r1.535 src/sys/kern/kern_exec.c
cvs rdiff -u -r1.22 -r1.23 src/tests/kernel/t_signal_and_sp.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60653 CVS commit: src
Date: Fri, 28 Aug 2026 12:04:02 +0000
Module Name: src
Committed By: riastradh
Date: Fri Aug 28 12:04:02 UTC 2026
Modified Files:
src/sys/kern: kern_fork.c
src/tests/kernel: t_signal_and_sp.c
Log Message:
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
To generate a diff of this commit:
cvs rdiff -u -r1.234 -r1.235 src/sys/kern/kern_fork.c
cvs rdiff -u -r1.23 -r1.24 src/tests/kernel/t_signal_and_sp.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60653 CVS commit: src/sys
Date: Fri, 28 Aug 2026 13:58:27 +0000
Module Name: src
Committed By: riastradh
Date: Fri Aug 28 13:58:27 UTC 2026
Modified Files:
src/sys/kern: kern_fork.c
src/sys/sys: proc.h
Log Message:
struct proc: Put p_stackbase in the [p_startcopy,p_endcopy) range.
It is inherited by the child because the child has exactly the same
memory layout as the parent.
Cleanup after:
PR kern/60653: posix_spawn(3) causes incorrect stack base information
XXX kernel ABI revbump -- NOT FOR PULLUP
To generate a diff of this commit:
cvs rdiff -u -r1.235 -r1.236 src/sys/kern/kern_fork.c
cvs rdiff -u -r1.374 -r1.375 src/sys/sys/proc.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60653 CVS commit: src/sys/sys
Date: Fri, 28 Aug 2026 14:03:32 +0000
Module Name: src
Committed By: riastradh
Date: Fri Aug 28 14:03:32 UTC 2026
Modified Files:
src/sys/sys: param.h
Log Message:
sys/param.h: Welcome to 11.99.8, courtsey of struct proc reordering.
PR kern/60653: posix_spawn(3) causes incorrect stack base information
XXX kernel ABI revbump -- NOT FOR PULLUP
To generate a diff of this commit:
cvs rdiff -u -r1.746 -r1.747 src/sys/sys/param.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: feedback->pending-pullups
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Sat, 05 Sep 2026 08:46:20 +0000
State-Changed-Why:
fixed in HEAD
pullup-11
pullup-10
?
State-Changed-From-To: pending-pullups->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Thu, 08 Oct 2026 16:00:43 +0000
State-Changed-Why:
I don't see evidence of pullups being pending, still need to request them.
From: "Robert Bagdan" <kikadf@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60653 CVS commit: pkgsrc/devel/libuv
Date: Mon, 19 Oct 2026 06:53:57 +0000
Module Name: pkgsrc
Committed By: kikadf
Date: Mon Oct 19 06:53:57 UTC 2026
Modified Files:
pkgsrc/devel/libuv: Makefile distinfo
pkgsrc/devel/libuv/patches: patch-src_unix_process.c
Log Message:
libuv: use fork instead of posix_spawn on NetBSD
while fix not available for:
PR kern/60653: posix_spawn(3) causes incorrect stack base information
Ok from @agc
To generate a diff of this commit:
cvs rdiff -u -r1.92 -r1.93 pkgsrc/devel/libuv/Makefile
cvs rdiff -u -r1.90 -r1.91 pkgsrc/devel/libuv/distinfo
cvs rdiff -u -r1.1 -r1.2 pkgsrc/devel/libuv/patches/patch-src_unix_process.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Tue, 20 Oct 2026 21:10:05 +0000
State-Changed-Why:
pullup-11 #541
pullup-10 #1386
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60653 CVS commit: [netbsd-11] src
Date: Sat, 24 Oct 2026 10:26:02 +0000
Module Name: src
Committed By: martin
Date: Sat Oct 24 10:26:02 UTC 2026
Modified Files:
src/distrib/sets/lists/debug [netbsd-11]: mi
src/distrib/sets/lists/tests [netbsd-11]: mi
src/sys/compat/linux32/arch/aarch64 [netbsd-11]: linux32_exec_machdep.c
src/sys/compat/netbsd32 [netbsd-11]: netbsd32_signal.c
src/sys/kern [netbsd-11]: exec_script.c exec_subr.c kern_exec.c
kern_fork.c
src/tests/kernel [netbsd-11]: Makefile t_signal_and_sp.c
Added Files:
src/tests/kernel [netbsd-11]: getstack.c getstack.h h_getstack.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #541):
sys/compat/netbsd32/netbsd32_signal.c: revision 1.57
tests/kernel/h_getstack.c: revision 1.1
sys/kern/kern_fork.c: revision 1.235
sys/kern/exec_subr.c: revision 1.93
tests/kernel/Makefile: revision 1.100
tests/kernel/t_signal_and_sp.c: revision 1.22
tests/kernel/t_signal_and_sp.c: revision 1.23
tests/kernel/t_signal_and_sp.c: revision 1.24
distrib/sets/lists/tests/mi: revision 1.1429
tests/kernel/Makefile: revision 1.99
distrib/sets/lists/debug/mi: revision 1.518
tests/kernel/getstack.c: revision 1.1
sys/compat/linux32/arch/aarch64/linux32_exec_machdep.c: revision 1.3
tests/kernel/getstack.h: revision 1.1
sys/kern/kern_exec.c: revision 1.534
sys/kern/kern_exec.c: revision 1.535
sys/kern/exec_script.c: revision 1.86
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.485.2.13 -r1.485.2.14 src/distrib/sets/lists/debug/mi
cvs rdiff -u -r1.1387.2.13 -r1.1387.2.14 src/distrib/sets/lists/tests/mi
cvs rdiff -u -r1.2 -r1.2.8.1 \
src/sys/compat/linux32/arch/aarch64/linux32_exec_machdep.c
cvs rdiff -u -r1.55 -r1.55.2.1 src/sys/compat/netbsd32/netbsd32_signal.c
cvs rdiff -u -r1.85 -r1.85.2.1 src/sys/kern/exec_script.c
cvs rdiff -u -r1.91 -r1.91.2.1 src/sys/kern/exec_subr.c
cvs rdiff -u -r1.531.2.1 -r1.531.2.2 src/sys/kern/kern_exec.c
cvs rdiff -u -r1.232 -r1.232.2.1 src/sys/kern/kern_fork.c
cvs rdiff -u -r1.96.2.2 -r1.96.2.3 src/tests/kernel/Makefile
cvs rdiff -u -r0 -r1.1.2.2 src/tests/kernel/getstack.c \
src/tests/kernel/getstack.h src/tests/kernel/h_getstack.c
cvs rdiff -u -r1.21 -r1.21.2.1 src/tests/kernel/t_signal_and_sp.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60653 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.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60653 CVS commit: [netbsd-10] src/sys/compat/linux32/arch/aarch64
Date: Sat, 24 Oct 2026 11:07:37 +0000
Module Name: src
Committed By: martin
Date: Sat Oct 24 11:07:37 UTC 2026
Modified Files:
src/sys/compat/linux32/arch/aarch64 [netbsd-10]: linux32_exec_machdep.c
Log Message:
Pull up the following requested by riastradh in ticket #1386:
sys/compat/linux32/arch/aarch64/linux32_exec_machdep.c 1.3 (patch)
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
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r1.1.4.1 \
src/sys/compat/linux32/arch/aarch64/linux32_exec_machdep.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home