From owner-freebsd-bugs@FreeBSD.ORG Mon Jul 2 18:30:10 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C77C106566B for ; Mon, 2 Jul 2012 18:30:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2169E8FC16 for ; Mon, 2 Jul 2012 18:30:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q62IUAU9078227 for ; Mon, 2 Jul 2012 18:30:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q62IU9gM078224; Mon, 2 Jul 2012 18:30:09 GMT (envelope-from gnats) Resent-Date: Mon, 2 Jul 2012 18:30:09 GMT Resent-Message-Id: <201207021830.q62IU9gM078224@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, deeptech71 Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAF68106566C for ; Mon, 2 Jul 2012 18:29:51 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 95F5C8FC17 for ; Mon, 2 Jul 2012 18:29:51 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q62ITp1G034724 for ; Mon, 2 Jul 2012 18:29:51 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q62ITpvf034723; Mon, 2 Jul 2012 18:29:51 GMT (envelope-from nobody) Message-Id: <201207021829.q62ITpvf034723@red.freebsd.org> Date: Mon, 2 Jul 2012 18:29:51 GMT From: deeptech71 To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: misc/169608: the mmap(), mprotect(), and munmap() functions get fucked by some corner-case arguments X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 18:30:10 -0000 >Number: 169608 >Category: misc >Synopsis: the mmap(), mprotect(), and munmap() functions get fucked by some corner-case arguments >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jul 02 18:30:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: deeptech71 >Release: -CURRENT >Organization: >Environment: FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r237587M: Tue Jun 26 07:19:02 CEST 2012 root@:/usr/obj/usr/src/sys/HQ i386 >Description: As it turns out, the mmap(), mprotect(), and munmap() functions behave very badly when they are handed some corner-case arguments. Their behavior is also inconsistent with the descriptions in the man pages. Not to mention that, as I'd say, the man pages are very poor (which is definitely true compared to Linux's man pages). See the (to be) attached test program, execution script, and sample output; these are for/on 32-bit machines. The WRONGly looking pieces of output are: * [6/30] mmap(0x0, 4294967295, PROT_READ | PROT_WRITE, MAP_ANON, -1, 0)... success: got 0x28049000; writing here... Segmentation fault (core dumped) mmap() returns a "successful" pointer, but the area is not writable. Also see cases [12/30], [18/30], and [24/30] for mmap(). * [14/30] mmap(0xdeadbeef, 4096, PROT_READ | PROT_WRITE, MAP_ANON, -1, 0)... Cannot allocate memory A hint (a non-NULL first argument) should not interfere with mmap()'s ability to succeed in allocating memory. Also see cases [15/30], [20/30], and [21/30] for mmap(). * [30/30] mmap(0xffffffff, 4294967295, PROT_READ | PROT_WRITE, MAP_ANON, -1, 0)... No such file or directory WTF?! * [6/30] mprotect(0x0, 4294967295, PROT_NONE)... success! Did mprotect() really restrict ~4GiB of memory? Also see cases [11/30], [12/30], [17/30], [18/30], [24/30], and [29/30] for mprotect(). Notably, 0xfffff000 seems to play along with 4294967295, but not 4294963200; while 0xffffffff seems to play along with 4294963200, but not 4294967295. * [8/30] munmap(0xbeef, 4096)... success! 0xBEEF is not page-aligned, but the man page says that it should be. Also, see many other cases for munmap(). * [11/30] munmap(0xbeef, 4294963200)... success! Did munmap() really unmap ~4GiB of memory? Also see case [12/30] for munmap(). As a comparison, the output on a (64-bit) Linux machine suggests that Linux's relevant functions are more robust. BTW: The man page for munmap() says that the function will set errno to EINVAL if "The addr argument was not page aligned, the len argument was zero or negative, or some part of the region being unmapped is outside the valid address range for a process.". Negative size_t? You've gotta be kidding me! >How-To-Repeat: Compile xs.c (to a.out), and then run the r.sh script. (These files are to be attached.) >Fix: >Release-Note: >Audit-Trail: >Unformatted: