Bug 507017 - mmap_min_addr can trigger on non MAP_FIXED mmap operations
Summary: mmap_min_addr can trigger on non MAP_FIXED mmap operations
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Eric Paris
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-19 20:38 UTC by Eric Paris
Modified: 2009-09-02 08:57 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-02 08:57:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1243 0 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 5.4 kernel security and bug fix update 2009-09-01 08:53:34 UTC

Description Eric Paris 2009-06-19 20:38:31 UTC
mmap_min_addr is intended to prevent a process from mmaping virtual memory below a certain point.  This is useful in hardening the kernel again subversion in the face of NULL ptr bugs.  We currently set the minimum threshold to 65535 in RHEL kernels.

The fedora infrastructure got a number of mmap_zero selinux denials.  In investigating why selinux was denying mmap to low pages we found audit syscall records like so:

type=SYSCALL arch=i386 syscall=mmap2 success=no exit=-13(Permission denied) a0=0 a1=1000 a2=3 a3=22

looking at a0-a4 we see that the program called

mmap(NULL, PAGE_SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE,...)

which is a perfectly legal call to mmap.  But SELinux denied the call with:

node=10.8.34.193 type=AVC msg=audit(06/16/2009 03:15:50.856:139394) : avc:  denied  { mmap_zero } for  pid=25660 comm=httpd scontext=user_u:system_r:httpd_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=memprotect 

(which explains the errno=EACCESS on the mmap)

This means that the program was allowing the kernel to pick an address for the mmap location and the kernel picked an address < 64k.  Upon code review Rik van Riel pointed me to arch_get_unmapped_area_topdown() which walks down the virtual memory space looking for room to make an allocation.  It will allocate all the way down to the first page (but not the zero page)  So if the process is running low on virtual memory space, or if they have just done a LOT of mmap calls they could push into this range and get the accidental denials.

I propose as a solution for RHEL5 to change mmap_min_addr to only protect 0-4096 instead of 0-65535.  This should provide nearly the same protection (very few kernel structs and offsets are >4k but <64k) and is completely safe since the code has always protected against giving out the first 4k of space.

Upstream I am going to attempt to rewrite all of the *_get_unmapped_area_* functions to make sure they won't walk into mmap_min_addr space, but changes to such deep function in RHEL is inadvisable at best.

Comment 3 RHEL Program Management 2009-06-19 21:41:39 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 4 Don Zickus 2009-06-30 20:22:59 UTC
in kernel-2.6.18-156.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.

Comment 7 errata-xmlrpc 2009-09-02 08:57:10 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1243.html


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