NetBSD Problem Report #60838

From www@netbsd.org  Fri Oct  2 15:28:07 2026
Return-Path: <www@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) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "YR1" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id B39FA1A923B
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  2 Oct 2026 15:28:07 +0000 (UTC)
Message-Id: <20261002152806.120D41A923C@mollari.NetBSD.org>
Date: Fri,  2 Oct 2026 15:28:06 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: sparc fails to enforce RLIMIT_DATA on exec
X-Send-Pr-Version: www-1.0
X-From4GNATS: "campbell+netbsd@mumble.net via gnats" <gnats-admin@NetBSD.org>

>Number:         60838
>Category:       port-sparc
>Synopsis:       sparc fails to enforce RLIMIT_DATA on exec
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-sparc-maintainer
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 02 15:30:00 +0000 2026
>Closed-Date:    
>Last-Modified:  Fri Oct 02 17:23:19 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
The NexecBSData Limitation, Inc.
>Environment:
NetBSD 11.99.8 (GENERIC) #0: Thu Oct 1 15:43:13 UTC 2026 root@babylon5.netbsd.org:/tmp/build/2026.10.01.07.32.34-sparc/obj/sys/arch/sparc/compile/GENERIC
>Description:

	sparc -- and only sparc, as far as I have seen -- apparently
	fails to enforce RLIMIT_DATA on exec/spawn, which is weird
	because the RLIMIT_DATA logic is machine-independent.

	The evidence of this is that the kernel/t_signal_and_sp test
	case getstack_failedexec_rlimit_data `exited normally but
	failed to create the results file', which means that the exec
	call unexpectedly _succeeded_ and replaced the atf process
	image by another one, confusing atf:

FAILED: Test case exited normally but failed to create the results file: Failed to open /tmp/atf-run.6XWFoY/tcr

	https://releng.netbsd.org/b5reports/sparc/2026/2026.10.01.07.32.34/test.html#kernel_t_signal_and_sp_getstack_failedexec_rlimit_data

	Similarly, posix_spawn failed to fail:

*** Check failed: /tmp/build/2026.10.01.07.32.34-sparc/src/tests/kernel/t_signal_and_sp.c:884: Expected true value in (errno = posix_spawn(&pid, argv[0], NULL, NULL, argv, NULL)) != 0

	https://releng.netbsd.org/b5reports/sparc/2026/2026.10.01.07.32.34/test.html#kernel_t_signal_and_sp_getstack_failedspawn_rlimit_data

>How-To-Repeat:

	cd /usr/tests/kernel
	atf-run t_signal_and_sp | atf-report

>Fix:

	Yes, please!

	Perhaps there is something funny about ELF images on sparc that
	makes the machine-independent RLIMIT_DATA check logic not apply
	like it does everywhere else?

>Release-Note:

>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/60838: sparc fails to enforce RLIMIT_DATA on exec
Date: Fri, 2 Oct 2026 15:55:07 +0000

 Not just 32-bit sparc but also sparc64:

 https://releng.netbsd.org/b5reports/sparc64/2026/2026.10.01.07.32.34/test.h=
 tml#kernel_t_signal_and_sp_getstack_failedexec_rlimit_data

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/60838 CVS commit: src/tests/kernel
Date: Fri, 2 Oct 2026 16:22:24 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Fri Oct  2 16:22:24 UTC 2026

 Modified Files:
 	src/tests/kernel: t_signal_and_sp.c

 Log Message:
 t_signal_and_sp: Mark exec/spawn tests xfail on sparc.

 PR port-sparc/60838: sparc fails to enforce RLIMIT_DATA on exec


 To generate a diff of this commit:
 cvs rdiff -u -r1.24 -r1.25 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@NetBSD.org, netbsd-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/60838: sparc fails to enforce RLIMIT_DATA on exec
Date: Fri, 2 Oct 2026 16:43:03 +0000

 Looks like the kernel might consider the executable in question to
 have zero data size because all LOAD segments have the X bit set
 (/bin/sh, but I also checked a couple others, /bin/ls, /bin/sync, and
 /usr/bin/awk on sparc64, and they have the same pattern):

 $ readelf -l ./bin/sh
 ...
   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
 ...
   LOAD           0x000000 0x00010000 0x00010000 0x30760 0x30760 R E 0x10000
   LOAD           0x030760 0x00050760 0x00050760 0x00af4 0x02468 RWE 0x10000

 (Here `E' means execute, which I'm also calling `X' because the
 constant is named PF_X and colloquially it's known as the eXecute
 bit in the context of, e.g., W^X protection.)

 So the kernel will consider them both to be `text segment', and
 neither to be `data segment', and eventually conclude that the
 executable's `data size' is zero:

     703 	epp->ep_taddr = epp->ep_tsize = ELFDEFNNAME(NO_ADDR);
     704 	epp->ep_daddr = epp->ep_dsize = ELFDEFNNAME(NO_ADDR);
 ...
     776 			/*
     777 			 * Consider this as text segment, if it is executable.
     778 			 * If there is more than one text segment, pick the
     779 			 * largest.
     780 			 */
     781 			if (ph[i].p_flags & PF_X) {
     782 				if (epp->ep_taddr == ELFDEFNNAME(NO_ADDR) ||
     783 				    size > epp->ep_tsize) {
     784 					epp->ep_taddr = addr;
     785 					epp->ep_tsize = size;
     786 				}
     787 				end_text = addr + size;
     788 			} else {
     789 				epp->ep_daddr = addr;
     790 				epp->ep_dsize = size;
     791 			}
 ...
     828 	if (epp->ep_daddr == ELFDEFNNAME(NO_ADDR)) {
     829 		epp->ep_daddr = round_page(end_text);
     830 		epp->ep_dsize = 0;
     831 	}

 https://nxr.NetBSD.org/xref/src/sys/kern/exec_elf.c?r=1.107#776

 Is it expected that sparc executables have only RX and RWX segments,
 no separate R or RW segments?  Does sparc have some stupid ABI design
 that is incompatible with W^X?

From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/60838: sparc fails to enforce RLIMIT_DATA on exec
Date: Fri, 2 Oct 2026 17:19:01 +0000

 > Date: Fri, 2 Oct 2026 16:43:03 +0000
 > From: Taylor R Campbell <riastradh@NetBSD.org>
 >=20
 > Is it expected that sparc executables have only RX and RWX segments,
 > no separate R or RW segments?  Does sparc have some stupid ABI design
 > that is incompatible with W^X?

 Answer: looks like yes, the sparc and sparc64 PLT design in the SysV
 ABI relies on writable text at runtime to resolve symbols in PLT
 stubs, and that's what we do:

 https://nxr.NetBSD.org/xref/src/sys/arch/sparc/include/elf_support.h?r=3D1.=
 1#31
 https://nxr.NetBSD.org/xref/src/libexec/ld.elf_so/arch/sparc/mdreloc.c?r=3D=
 1.60#480

 And the .plt section is the only one having both write and execute
 flags in all the executables I checked.

 Apparently the VxWorks ABI supports secure-PLT through GOT indirection
 like ~every other architecture these days, but while binutils supports
 the VxWorks ABI and some people were talking about adapting it to what
 is presumably a SysV ABI context twenty years ago, it looks like that
 never happened:

 https://sourceware.org/pipermail/binutils/2006-March/046258.html

State-Changed-From-To: open->analyzed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 02 Oct 2026 17:23:19 +0000
State-Changed-Why:
probably won't be fixed until someone invents secure-plt for sparc
and teaches gcc/binutils and ld.elf_so how to do it


>Unformatted:

Home	PR Database Search