>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: _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
