Bug 708563 - 2.6.38.6-27.fc15.x86_64 kernel doesn't work with PIE when ASLR is disabled
Summary: 2.6.38.6-27.fc15.x86_64 kernel doesn't work with PIE when ASLR is disabled
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1039225
TreeView+ depends on / blocked
 
Reported: 2011-05-28 02:30 UTC by H.J. Lu
Modified: 2017-01-05 14:39 UTC (History)
5 users (show)

Fixed In Version: kernel-2.6.40.6-0.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1039225 (view as bug list)
Environment:
Last Closed: 2011-10-05 23:58:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Testcases (15.96 KB, application/x-bzip2)
2011-05-28 02:30 UTC, H.J. Lu
no flags Details
This patch works for me (817 bytes, patch)
2011-09-29 03:04 UTC, H.J. Lu
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Linux Kernel 36372 0 None None None Never
Red Hat Bugzilla 1410097 0 unspecified CLOSED kernel: too small userspace stack allocated for PIE binary 2021-02-22 00:41:40 UTC

Internal Links: 1410097

Description H.J. Lu 2011-05-28 02:30:26 UTC
Created attachment 501431 [details]
Testcases

Some PIE programs will fail with

# echo 0 > /proc/sys/kernel/randomize_va_space

I got

[root@gnu-68 168.wupwise]# echo 0 > /proc/sys/kernel/randomize_va_space
[root@gnu-68 168.wupwise]# ./wupwise
Killed
[root@gnu-68 168.wupwise]# echo 2 > /proc/sys/kernel/randomize_va_space
[root@gnu-68 168.wupwise]# ./wupwise
  RANDOM SOURCE
  SEED :     2123    1642    4095    1001
  KAPPA :  ( 0.23999999999999999     ,  0.0000000000000000     )
  NITER :           75

[root@gnu-68 168.wupwise]#

Comment 1 Josh Boyer 2011-09-28 16:55:58 UTC
This still seems to happen with 2.6.40 (3.0), though your provided testcases never actually works as shown in the output because it's missing some kind of .in file.  However, it runs and spits an error out in the randomize_va_space = 2 case, and gets killed otherwise.

Poking around with ftrace a bit, it seems it's getting killed around here in load_elf_binary:

	/* Calling set_brk effectively mmaps the pages that we need
	 * for the bss and break sections.  We must do this before
	 * mapping in the interpreter, to make sure it doesn't wind
	 * up getting placed where the bss needs to go.
	 */
	retval = set_brk(elf_bss, elf_brk);
	if (retval) {
		send_sig(SIGKILL, current, 0);
		goto out_free_dentry;
	}
	if (likely(elf_bss != elf_brk) && unlikely(padzero(elf_bss))) {
		send_sig(SIGSEGV, current, 0);
		retval = -EFAULT; /* Nobody gets to see this, but.. */
		goto out_free_dentry;
	}

It seems that the set_brk call is failing here, though I don't really know why at the moment.

Comment 2 Josh Boyer 2011-09-29 01:00:17 UTC
The place returning an error (-ENOMEM to be exact) is get_unmapped_area_prot in mm/mmap.c around line 1591:

	if (addr > TASK_SIZE - len)
		return -ENOMEM;

get_area is returning an address, which is valid, but the resulting address is larger than TASK_SIZE minus the area being mapped (I think).  The values in question turn out to be:

addr: 7ffff81ff000
TASK_SIZE: 7ffffffff000
len: afc8000
(TASK_SIZE - len): 7ffff5037000

I still have little clue why this is an error in the non-randomize case, but it seems that the len value corresponds to the .bss section size (roughly) in the binary:

[root@localhost ~]# readelf -S /home/jwboyer/wupwise | grep -3 bss
       00000000000000b8  0000000000000008  WA       0     0     8
  [26] .data             PROGBITS         0000000000207700  00007700
       0000000000000004  0000000000000000  WA       0     0     4
  [27] .bss              NOBITS           0000000000207720  00007720
       000000000afc8020  0000000000000000  WA       0     0     32
  [28] .comment          PROGBITS         0000000000000000  00007704
       0000000000000058  0000000000000001  MS       0     0     1

Comment 3 H.J. Lu 2011-09-29 03:04:13 UTC
Created attachment 525432 [details]
This patch works for me

Comment 4 Josh Boyer 2011-09-29 10:40:06 UTC
(In reply to comment #3)
> Created attachment 525432 [details]
> This patch works for me

Can you send that upstream for review?

Comment 5 H.J. Lu 2011-09-29 15:34:25 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Created attachment 525432 [details]
> > This patch works for me
> 
> Can you send that upstream for review?

I already did with the upstream bug report.

Comment 6 Josh Boyer 2011-09-29 15:55:33 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Created attachment 525432 [details]
> > > This patch works for me
> > 
> > Can you send that upstream for review?
> 
> I already did with the upstream bug report.

Great!  Since nobody can read that at the moment, and Google hasn't indexed it, could you paraphrase any discussion that happened?

Comment 7 H.J. Lu 2011-09-29 16:10:23 UTC
(In reply to comment #6)
> 
> Great!  Since nobody can read that at the moment, and Google hasn't indexed it,
> could you paraphrase any discussion that happened?

I don't remember there are any discussions.

Comment 8 Josh Boyer 2011-09-29 18:45:33 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > 
> > Great!  Since nobody can read that at the moment, and Google hasn't indexed it,
> > could you paraphrase any discussion that happened?
> 
> I don't remember there are any discussions.

That's likely because bugzilla.kernel.org is kind of a wasteland.

The patch does look like it would work for this, but I'd really like to get some more review of it before we add it.  Can you add a changelog and Signed-off-by to it and send it to andrew morton and al viro with lkml on CC by chance?

Comment 9 H.J. Lu 2011-09-29 18:59:24 UTC
(In reply to comment #8)
>
> The patch does look like it would work for this, but I'd really like to get
> some more review of it before we add it.  Can you add a changelog and
> Signed-off-by to it and send it to andrew morton and al viro with lkml on CC by
> chance?

Can you do it for me? It is a very small change.  Thanks.

Comment 10 Josh Boyer 2011-09-29 19:38:17 UTC
(In reply to comment #9)
> (In reply to comment #8)
> >
> > The patch does look like it would work for this, but I'd really like to get
> > some more review of it before we add it.  Can you add a changelog and
> > Signed-off-by to it and send it to andrew morton and al viro with lkml on CC by
> > chance?
> 
> Can you do it for me? It is a very small change.  Thanks.

I'm going to take that as an implicit Signed-off-by addition then.  I'll send it upstream with you on CC and we'll see what comes from it.

Comment 11 Josh Boyer 2011-10-03 18:51:06 UTC
I've committed Jiri's patch to fix this bug. 

http://article.gmane.org/gmane.linux.kernel/1198674

If there are further iterations, we can change the patch if necessary.  This should be in the next F15 kernel build.

Comment 12 Fedora Update System 2011-10-04 14:13:35 UTC
kernel-2.6.40.6-0.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/kernel-2.6.40.6-0.fc15

Comment 13 Fedora Update System 2011-10-05 03:58:24 UTC
Package kernel-2.6.40.6-0.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-2.6.40.6-0.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/kernel-2.6.40.6-0.fc15
then log in and leave karma (feedback).

Comment 14 Fedora Update System 2011-10-05 23:58:09 UTC
kernel-2.6.40.6-0.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.