NetBSD Problem Report #60877
From martin@duskware.de Wed Oct 14 18:20:29 2026
Return-Path: <martin@duskware.de>
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 "YR1" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id DAD1D1A923B
for <gnats-bugs@gnats.NetBSD.org>; Wed, 14 Oct 2026 18:20:29 +0000 (UTC)
Message-Id: <20261014182026.048B8E1FFAA@mail.duskware.de>
Date: Wed, 14 Oct 2026 20:20:20 +0200 (CEST)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: t_signal_and_sp test failure with i386 userland on amd64 kernel
X-Send-Pr-Version: 3.95
X-From4GNATS: "martin@NetBSD.org via gnats" <gnats-admin@NetBSD.org>
>Number: 60877
>Category: kern
>Synopsis: t_signal_and_sp test failure with i386 userland on amd64 kernel
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: pending-pullups
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Oct 14 18:25:00 +0000 2026
>Closed-Date:
>Last-Modified: Sat Oct 24 10:40:04 +0000 2026
>Originator: Martin Husemann
>Release: NetBSD 11.99.9
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD seven-days-to-the-wolves.aprisoft.de 11.99.9 NetBSD 11.99.9 (GENERIC) #903: Wed Oct 14 14:46:31 CEST 2026 martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
When running the i386 tests on an amd64 machine (in a 32bit chroot)
the /usr/tests/kernel/t_signal_and_sp test program shows lots of
failures, like:
tc-start: 1792001789.340810, getstack_vforkexec
tc-so:child
tc-se:h_getstack: ELF AT_STACKBASE: addr=0xffff4000
tc-se:h_getstack: getcontext: addr=0xfffff000 used=2000
tc-se:h_getstack: __ps_strings: addr=0xffff4000
tc-se:h_getstack: pthread attr: addr=0xffff4000 size=400000
tc-se:h_getstack: RLIMIT_STACK: size=400000 min, 4000000 max
tc-se:h_getstack: sigaltstack: addr=0x0 size=0
tc-se:h_getstack: Stack disagreement!
tc-so:parent
tc-se:*** Check failed: /work/src/tests/kernel/t_signal_and_sp.c:779: child exited with code 255
tc-se:t_signal_and_sp: ELF AT_STACKBASE: addr=0xfff6d000
tc-se:t_signal_and_sp: getcontext: addr=0xfffff000 used=3000
tc-se:t_signal_and_sp: __ps_strings: addr=0xfff6d000
tc-se:t_signal_and_sp: pthread attr: addr=0xfff6d000 size=400000
tc-se:t_signal_and_sp: RLIMIT_STACK: size=400000 min, 4000000 max
tc-se:t_signal_and_sp: sigaltstack: addr=0x0 size=0
tc-se:t_signal_and_sp: Stack disagreement!
tc-se:*** Check failed: /work/src/tests/kernel/t_signal_and_sp.c:786: checkgetstack() == 0 not met
tc-end: 1792001789.344804, getstack_vforkexec, failed, 2 checks failed; see output for more details
see also:
https://netbsd.org/~martin/amd64-compat32-atf/
>How-To-Repeat:
s/a
>Fix:
n/a
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Wed, 14 Oct 2026 19:32:59 +0000
State-Changed-Why:
candidate fix committed, needs pullup-11, pullup-10 after test run
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/60877 CVS commit: src/sys/compat/netbsd32
Date: Wed, 14 Oct 2026 19:32:04 +0000
Module Name: src
Committed By: riastradh
Date: Wed Oct 14 19:32:04 UTC 2026
Modified Files:
src/sys/compat/netbsd32: netbsd32_signal.c
Log Message:
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
>
> Modified Files:
> src/sys/conf: files
> src/sys/kern: exec_elf32.c exec_subr.c init_sysctl.c kern_exec.c
> kern_pax.c kern_sig.c
> src/sys/sys: exec.h exec_elf.h pax.h proc.h
> src/sys/uvm: uvm_extern.h uvm_mmap.c
>
> Log Message:
> 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.56 -r1.57 src/sys/compat/netbsd32/netbsd32_signal.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: Wed, 21 Oct 2026 02:45:43 +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/60877 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/60877 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.
>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