NetBSD Problem Report #41877

From Manuel.Bouyer@lip6.fr  Wed Aug 12 12:01:58 2009
Return-Path: <Manuel.Bouyer@lip6.fr>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id DA04363C270
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 12 Aug 2009 12:01:57 +0000 (UTC)
Message-Id: <20090812120156.368535030@disco.asim.lip6.fr>
Date: Wed, 12 Aug 2009 14:01:56 +0200 (MEST)
From: Manuel.Bouyer@lip6.fr
Reply-To: Manuel.Bouyer@lip6.fr
To: gnats-bugs@gnats.NetBSD.org
Subject: PaX ASLR reduces available stack size
X-Send-Pr-Version: 3.95

>Number:         41877
>Category:       kern
>Synopsis:       PaX ASLR reduces available stack size
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 12 12:05:00 +0000 2009
>Closed-Date:    Thu Jul 06 00:47:30 +0000 2023
>Last-Modified:  Thu Jul 06 00:47:30 +0000 2023
>Originator:     Manuel Bouyer
>Release:        NetBSD 5.0_STABLE
>Organization:
>Environment:
System: NetBSD disco 5.0_STABLE NetBSD 5.0_STABLE (DISCO) #3: Fri Aug 7 08:59:42 MEST 2009 bouyer@disco:/home/bouyer/src-5/src/sys/arch/i386/compile/obj/DISCO i386
Architecture: i386
Machine: i386
>Description:
	Enabling PaX ASLR on a server, some programs started to
	randomly dump core. gdb revealed that they did get a
	segmentation fault trying to write to the stack, and indeed
	the address at %esp is not mapped. The stack size is the default
	for i386 (2Mb).
	So I wrote this test program:
#define ALLOCASZ (2048 * 1024 - 4096 * 3) /* largest size that doesn't segv */
main()
{
int i;
char *c = alloca(ALLOCASZ);
printf("0x%lx 0x%lx 0x%lx\n", (long)(&i), (long)(&c[0]), (long)(&c[ALLOCASZ]));
c[0]=1;
c[ALLOCASZ]=1;
exit(0);
}
	Without ASLR it executes as:
# ./test
0xbf7fee4c 0xbf601e30 0xbf7fee30
	(with of course repeteable results).
	With ASLR (and kernel build with PAX_DEBUG):
# paxctl +A ./test
# ./test
stack 0xbf800000 d=0xce1000 0xbeb1f000
applying to 0xbb7f8000 orig_addr=0x0 f=1002
result 0xb714c000
applying to 0xbb7ff000 orig_addr=0x0 f=1
result 0xb7153000
applying to 0xbb710000 orig_addr=0x0 f=2
result 0xb7064000
not applying to 0xb7134000 orig_addr=0xb7134000 f=12
not applying to 0xb713c000 orig_addr=0xb713c000 f=1012
applying to 0xbb700000 orig_addr=0x0 f=14001002
result 0xb7054000
0xbeb1d70c 0xbe9206f0 0xbeb1d6f0
# ./test
stack 0xbf800000 d=0xa1a000 0xbede6000
applying to 0xbb7f8000 orig_addr=0x0 f=1002
result 0xb1e10000
applying to 0xbb7ff000 orig_addr=0x0 f=1
result 0xb1e17000
applying to 0xbb710000 orig_addr=0x0 f=2
result 0xb1d28000
not applying to 0xb1df8000 orig_addr=0xb1df8000 f=12
not applying to 0xb1e00000 orig_addr=0xb1e00000 f=1012
applying to 0xbb700000 orig_addr=0x0 f=14001002
result 0xb1d18000
0xbede4b6c 0xbebe7b50 0xbede4b50
[...]
# ./test
stack 0xbf800000 d=0x971000 0xbee8f000
applying to 0xbb7f8000 orig_addr=0x0 f=1002
result 0xba4ac000
applying to 0xbb7ff000 orig_addr=0x0 f=1
result 0xba4b3000
applying to 0xbb710000 orig_addr=0x0 f=2
result 0xba3c4000
not applying to 0xba494000 orig_addr=0xba494000 f=12
not applying to 0xba49c000 orig_addr=0xba49c000 f=1012
pid 57 (test), uid 0: exited on signal 11 (core dumped)
Memory fault (core dumped)
# gdb test test.core
Core was generated by `test'.
Program terminated with signal 11, Segmentation fault.
#0  0xbb7f6dc3 in _rtld_find_symdef () from /usr/libexec/ld.elf_so
(gdb) info reg
eax            0xa77    2679
ecx            0xba4ae400       -1169497088
edx            0xba3d9b90       -1170367600
ebx            0xbb7fee60       -1149243808
esp            0xbec8effc       0xbec8effc
ebp            0xbec8f4e8       0xbec8f4e8
esi            0xdd828  907304
edi            0xba3bc000       -1170489344
eip            0xbb7f6dc3       0xbb7f6dc3 <_rtld_find_symdef+7>
eflags         0x10296  [ PF AF SF IF RF ]
cs             0x17     23
ss             0x1f     31
ds             0x1f     31
es             0x1f     31
fs             0x1f     31
gs             0x1f     31
(gdb) disas 0xbb7f6dc3
Dump of assembler code for function _rtld_find_symdef:
0xbb7f6dbc <_rtld_find_symdef+0>:       push   %ebp
0xbb7f6dbd <_rtld_find_symdef+1>:       push   %edi
0xbb7f6dbe <_rtld_find_symdef+2>:       push   %esi
0xbb7f6dbf <_rtld_find_symdef+3>:       push   %ebx
0xbb7f6dc0 <_rtld_find_symdef+4>:       sub    $0x1c,%esp
0xbb7f6dc3 <_rtld_find_symdef+7>:       call   0xbb7f6dc8 <_rtld_find_symdef+12>

So, even though pax_aslr_stack() always returns a pointer aligned on
page size, ALSR causes something to consume a variable amount of
stack size before main() is called, which causes the executed program to
have a smaller stack size than expected and eventually core dump.

>How-To-Repeat:
	See above
>Fix:
	unknow

>Release-Note:

>Audit-Trail:
From: Pierre Pronchery <khorben@defora.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/41877: PaX ASLR reduces available stack size
Date: Wed, 4 Jan 2012 02:00:40 +0100

 --d6Gm4EdcadzBjdND
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable

 			Hi,

 testing Manuel's program in this problem report seems to work reliably
 for me with the following change, which reduced the memory allocation on
 the stack by only 8 KB:
 #define ALLOCASZ (2048 * 1024 - 4096 * 5)

 This is true both on NetBSD/amd64 5.99.58 (from approximately December
 1st 2011) and on NetBSD/amd64 5.1_STABLE (tracking the netbsd-5 branch).

 In both cases I have set the stack size to the same value:
 $ ulimit -s 2048
 $ ulimit -s
 2048

 Setting ALLOCASZ to be bigger by just 4 KB triggers crashes after one to
 three attempts. I suppose that this behavior is as expected though;
 could it be that the modification pushed in kern/43773 fixed this report
 as well?

 HTH,
 --=20
 khorben

 --d6Gm4EdcadzBjdND
 Content-Type: application/pgp-signature
 Content-Disposition: inline

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (NetBSD)

 iQIcBAEBAgAGBQJPA6S4AAoJEDU4cZknVYg+cJ4P/2nwObd+5ajRI0jQg3SR67jN
 SUVPToNRIVP5XCwPaib4lXvrTe5n9zsqRJInDlb97KMBDjrx1AQ60viVeec/Ejss
 CoTaqvvnA+6xk2ytsAyFvgcREaSkYhXlo64qxqtFALtm2OXgcQm6XpqIHg3/Kc8e
 KfS5+/WeLEIv1TpIj6tySoEXHGe9H9h/h1SgwKkCH7n2jfhiUDREhSVqWA0pHkp6
 dIfcS5jROzE9GEOr+swi0mEoBsQ9/rMFnJqHDcSkPUZJ8hFTZIbG3bnp4u7ouZL9
 oDROyr7wIpl7Q6JCkXSwTvSM+QDhkv600tl0VCxd3mgPMkOL079oaESWXCXcXbBd
 cA9gPXh660qht0DF5hQuUDlSAKqBF51I8/QXKnxunPmiKRJKxe4EIVSTUROFMzw5
 tkemsUWWw6BDpIN5Rcx/b/5vPlOtiLp51Kbd8JeS7O7S0wKjoV7ojRZRFkwzFtwK
 Zo/SR1wiJ/GgiGo1FMjgEr2lhsKvDP77zIAoFqX3ulVMeepyu8DGAdZitbUPN27L
 KgPinrM9K/bs6nyWoFP9atkNMi5SNGPIufk1LpKhIM18a3dGg0IENaXCPt0UtmK+
 S4M1Ml/V5aQpVTfGg8NpkKWkWl7bNIi0RupaHsr+oMGOZDxh9dcLUCOQzRsbh6mL
 S9rooCewZyxtLrGJO8ND
 =iYdj
 -----END PGP SIGNATURE-----

 --d6Gm4EdcadzBjdND--

State-Changed-From-To: open->closed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Thu, 06 Jul 2023 00:47:30 +0000
State-Changed-Why:
Can't reproduce on amd64 or `i386' (-m32), probably fixed by the same
change that fixed https://gnats.netbsd.org/43773, please follow up if
the problem persists!


>Unformatted:

Home	PR Database Search