From nobody@FreeBSD.org  Wed Mar 22 09:24:49 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id C9A2116A41F
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 22 Mar 2006 09:24:49 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 383FA43D5E
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 22 Mar 2006 09:24:48 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k2M9OlpK073781
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 22 Mar 2006 09:24:47 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k2M9Olul073778;
	Wed, 22 Mar 2006 09:24:47 GMT
	(envelope-from nobody)
Message-Id: <200603220924.k2M9Olul073778@www.freebsd.org>
Date: Wed, 22 Mar 2006 09:24:47 GMT
From: Jan <jan@concept.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: mmap with given (void *addr) may lock memory-manager
X-Send-Pr-Version: www-2.3

>Number:         94827
>Category:       kern
>Synopsis:       [libc] mmap with given (void *addr) may lock memory-manager
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Mar 22 09:30:10 GMT 2006
>Closed-Date:    Wed Oct 21 03:33:49 UTC 2009
>Last-Modified:  Wed Oct 21 03:33:49 UTC 2009
>Originator:     Jan
>Release:        5.3
>Organization:
Concept Engineering GmbH
>Environment:
FreeBSD star2 5.3-RELEASE FreeBSD 5.3-RELEASE #4: Thu Nov 17 12:33:20 CET 2005     jrr@star2:/usr/src/sys/i386/compile/STAR2  i386

>Description:
Hi!

Given the following code:

-- 8< -- 
#include <sys/mman.h>
#include <stdlib.h>
#include <stdio.h>

int main(){
    printf("mmap: %p\n", mmap( (void*)0x1000, 0x8047004, PROT_NONE, 
                               MAP_PRIVATE|MAP_ANON|MAP_NORESERVE, -1, 0 ));
    printf("malloc: %p\n", malloc(4));
    return 42;
}
-- 8< -- 

returns NULL for the malloc on my machine ( also happens on 3.4-RELEASE; does
not fail on AIX/Solaris/Windows/Linux/HPUX )

It runs well if *addr is set to NULL or if the requestet memory is a bit
smaller. The prot. flags does not affect the behaviour.

>How-To-Repeat:
If the code doesnt show anything wrong, try to increase the requested mmap
mem. There seems to be a border at 0x8047000 on my machines. Anything below
0x8047000 works fine here.


>Fix:

In fact, i need a fix :)



>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-i386->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Tue Mar 28 09:28:52 UTC 2006 
Responsible-Changed-Why:  
This does not sound i386-specific. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=94827 
State-Changed-From-To: open->analyzed 
State-Changed-By: kris 
State-Changed-When: Sat Apr 1 19:13:59 UTC 2006 
State-Changed-Why:  
This is believed to be not a bug. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=94827 

From: Kris Kennaway <kris@obsecurity.org>
To: bug-followup@FreeBSD.org, jan@concept.de
Cc:  
Subject: Re: kern/94827
Date: Sat, 1 Apr 2006 14:13:36 -0500

 The problem is because you're mmapping at a specific address that
 happens to overlap with addresses used by malloc.  If you mmap(NULL,
 ...) then the kernel will allocate you an unused address.
 
 Kris
 
 

From: Jan Gutsche <jan@concept.de>
To: Kris Kennaway <kris@obsecurity.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/94827
Date: Tue, 4 Apr 2006 13:39:42 +0200 (CEST)

 On Sat, 1 Apr 2006, Kris Kennaway wrote:
 
 Hello Kris!
 
 > The problem is because you're mmapping at a specific address that
 > happens to overlap with addresses used by malloc.  If you mmap(NULL,
 > ...) then the kernel will allocate you an unused address.
 
 That makes sense. However it works on solaris/aix/hpux/linux. -> If there 
 is an overlap with memory used by "mallocs/memorymanager/..", your get a 
 different address than requested.
 
 Maybe the bugreport should be moved to "manpage bug" as it shouldn't be 
 allowed in general to mmap to specified address on FreeBSD (!?)
 
 Best Regards,
 
  		Jan
 
 
 --
    Jan Gutsche, Ph.D.             Tel +49 761 47094 16
    Concept Engineering GmbH       Fax +49 761 47094 29
    Boetzinger Str. 29             jan@concept.de
    D-79111 Freiburg, Germany      www.concept.de
 
State-Changed-From-To: analyzed->feedback 
State-Changed-By: rwatson 
State-Changed-When: Sat Mar 8 20:15:52 UTC 2008 
State-Changed-Why:  
When I try the test program with the incuded or larger memory sizes, it 
appears to work as desired in FreeBSD 7.0: if I don't specify MAP_FIXED, 
I get different memory addresses, but if I do specify MAP_FIXED, the next 
malloc coredumps due to mapping over memory owned by malloc.  Could you 
confirm that the problem you're experiencing exists in FreeBSD 7.0? 


http://www.freebsd.org/cgi/query-pr.cgi?pr=94827 
State-Changed-From-To: feedback->analyzed 
State-Changed-By: vwe 
State-Changed-When: Sat May 10 17:48:47 UTC 2008 
State-Changed-Why:  

no feedback received but enough analysis has already been done 

http://www.freebsd.org/cgi/query-pr.cgi?pr=94827 

From: Alexander Best <alexbestms@math.uni-muenster.de>
To: <bug-followup@FreeBSD.org>
Cc:  
Subject: Re: kern/94827: [libc] mmap with given (void *addr) may lock
 memory-manager
Date: Wed, 21 Oct 2009 02:59:22 +0200 (CEST)

 this PR can be closed. the results described by jan when running the example
 code can no longer be reproduced (running 9-CURRENT). both printfs return a
 unique address.
 
 the problem described by rwatson however still exists (again running
 9-CURRENT). if mmap is called with MAP_FIXED|MAP_ANON a segfault will occur.
 this problem however seems completely unrelated to this PR.
 
 alex
State-Changed-From-To: analyzed->closed 
State-Changed-By: linimon 
State-Changed-When: Wed Oct 21 03:32:40 UTC 2009 
State-Changed-Why:  
Apparently this has been fixed sometime in the past. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=94827 
>Unformatted:
