Bug 418341 - mono attempts to mmap 0 page with MAP_FIXED
mono attempts to mmap 0 page with MAP_FIXED
Product: Fedora
Classification: Fedora
Component: mono (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Alexander Larsson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-12-10 11:49 EST by Eric Paris
Modified: 2007-12-11 10:47 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-11 10:47:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eric Paris 2007-12-10 11:49:17 EST
On an F8 system with vm.mmap_min_addr = 65535 when logging onto my X session I
get an selinux denial from mono.

time->Mon Dec 10 11:31:54 2007
type=SYSCALL msg=audit(1197304314.200:45): arch=40000003 syscall=192 per=400000
success=no exit=-13 a0=1000 a1=2000 a2=3 a3=22 items=0 ppid=1 pid=4799 auid=500
uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500
tty=(none) comm="mono" exe="/usr/bin/mono"
subj=system_u:system_r:mono_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1197304314.200:45): avc:  denied  { mmap_zero } for  pid=4799
comm="mono" scontext=system_u:system_r:mono_t:s0-s0:c0.c1023
tcontext=system_u:system_r:mono_t:s0-s0:c0.c1023 tclass=memprotect

What this really means is that /usr/bin/mono tried get address space < 65536
available.  Typically this means it tried to call mmap (or mremap) with
MAP_FIXED and an address < 65536 (it could also be stack expansion and some
other things, but mmap() of 0 is by far the most common.

In trying to harden the kernel against escalation of priveledge attacks we are
no longer allowing these types of operations.  I'm not sure what mono was doing
during start up (pretty much just a stock F8 plus the sysctl change) or why it
needs to get access to this page.  But we either need to figure out why it is
required or we need to fix mono to stop doing this.

I will be turning these protections on by default in F9 and hopefully in RHEL5.2
as well.  Please explain why mono is doing this as soon as possible and even
better, make it stop.

Comment 1 Eric Paris 2007-12-10 12:21:10 EST
Just noticed I don't see tomboy running, was it tomboy that broke because of this?
Comment 2 Alexander Larsson 2007-12-11 05:50:17 EST
This is from the garbage collector. For heap allocation it uses mmap with
MAP_FIXED at the end of the last returned allocation as a hint to get a compact
heap (I believe). The initial value used is HEAP_START, which for linux is
(from libgc/include/private/gcconfig.h):
#       define HEAP_START (ptr_t)0x1000
                /* This encourages mmap to give us low addresses,       */
                /* thus allowing the heap to grow to ~3GB               */

To verify this, i tried vm.mmap_min_addr=4096 => OK, but vm.mmap_min_addr=4097
=> not OK.

Its easy to bump the HEAP_START to a larger value, but is there actually a
security advantage in having mmap_min_addr > 4096?
Comment 3 Alexander Larsson 2007-12-11 07:00:28 EST
BTW. This is the boehm garbage collector, used in many other apps. In fact, gcc
uses it for its java gc, and it seems to pick 0x1000 for HEAP_START too:
Comment 4 Eric Paris 2007-12-11 10:47:55 EST
closing.  not a bug.  sorry, i should have been using an F9 kernel which deals
with low HINT addresses.  F9 kernel (and the future RHEL5 kernel) handles low
hint addresses just fine (by rounding them up to min_addr.  This would still
blow up with MAP_FIXED, but with when it's only a hint no reason we should EPERM it.

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