mmap and then munmap, sometimes unmapped region can be accessed - linux

Question

I met this problem on vmware 11.0 and linux-2.6.34, with gcc 4.9.2, had not tested on real hardware.
Following code run successfully and message were printed without SIGSEGV. But if I uncommented the printf before munmap, a SIGSEGV were caught.
maps before and after munmap() were printed in following messages.
static void check_mmap(void){
int fd, i;
char *p = NULL;
if ((fd = shm_open("xxxxxxxxxxxx", O_RDWR|O_CREAT|O_TRUNC, 0666)) == -1) {
printf("open shm file failed.\n");
return;
}
if (ftruncate(fd, 4096) == -1)
goto out;
p = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
if (MAP_FAILED == p)
goto out;
//printf("Mapped at %p\n", p);
getchar(); // <----- chance to print maps befor munmap
if (munmap(p, 4096) != 0)
printf("munmap error: %s\n", strerror(errno));
printf("Corrupting mmap memory.\n");
for(i = 0; i < 4095; i ++)
p[i] = 0;
printf("Done\n");
getchar(); // <----- chance to print maps after munmap
out:
close(fd);
if (p)
munmap(p, 4096);
}
maps before munmap, shm xxxxxxxxxxxx is mmaped at 7f3f2683a000-7f3f2683b000
00400000-00401000 r-xp 00000000 00:14 121 /mnt/hgfs/vm_shared/asan/asan1
00600000-00601000 rw-p 00000000 00:14 121 /mnt/hgfs/vm_shared/asan/asan1
7f3f25ea6000-7f3f25ebd000 r-xp 00000000 08:02 347266 /lib64/libpthread-2.11.3.so
7f3f25ebd000-7f3f260bc000 ---p 00017000 08:02 347266 /lib64/libpthread-2.11.3.so
7f3f260bc000-7f3f260bd000 r--p 00016000 08:02 347266 /lib64/libpthread-2.11.3.so
7f3f260bd000-7f3f260be000 rw-p 00017000 08:02 347266 /lib64/libpthread-2.11.3.so
7f3f260be000-7f3f260c2000 rw-p 00000000 00:00 0
7f3f260c2000-7f3f2620e000 r-xp 00000000 08:02 298091 /lib64/libc-2.11.1.so
7f3f2620e000-7f3f2640d000 ---p 0014c000 08:02 298091 /lib64/libc-2.11.1.so
7f3f2640d000-7f3f26411000 r--p 0014b000 08:02 298091 /lib64/libc-2.11.1.so
7f3f26411000-7f3f26412000 rw-p 0014f000 08:02 298091 /lib64/libc-2.11.1.so
7f3f26412000-7f3f26417000 rw-p 00000000 00:00 0
7f3f26417000-7f3f2641e000 r-xp 00000000 08:02 335978 /lib64/librt-2.11.1.so
7f3f2641e000-7f3f2661d000 ---p 00007000 08:02 335978 /lib64/librt-2.11.1.so
7f3f2661d000-7f3f2661e000 r--p 00006000 08:02 335978 /lib64/librt-2.11.1.so
7f3f2661e000-7f3f2661f000 rw-p 00007000 08:02 335978 /lib64/librt-2.11.1.so
7f3f2661f000-7f3f2663d000 r-xp 00000000 08:02 260202 /lib64/ld-2.11.1.so
7f3f2682b000-7f3f2682e000 rw-p 00000000 00:00 0
7f3f26839000-7f3f2683a000 rw-p 00000000 00:00 0
7f3f2683a000-7f3f2683b000 rw-p 00000000 00:11 16078 /dev/shm/xxxxxxxxxxxx
7f3f2683b000-7f3f2683c000 rw-p 00000000 00:00 0
7f3f2683c000-7f3f2683d000 r--p 0001d000 08:02 260202 /lib64/ld-2.11.1.so
7f3f2683d000-7f3f2683e000 rw-p 0001e000 08:02 260202 /lib64/ld-2.11.1.so
7f3f2683e000-7f3f2683f000 rw-p 00000000 00:00 0
7fffd9ce3000-7fffd9d04000 rw-p 00000000 00:00 0 [stack]
7fffd9dff000-7fffd9e00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
maps after munmap, shm was successfully unmapped.
00400000-00401000 r-xp 00000000 00:14 121 /mnt/hgfs/vm_shared/asan/asan1
00600000-00601000 rw-p 00000000 00:14 121 /mnt/hgfs/vm_shared/asan/asan1
7f3f25ea6000-7f3f25ebd000 r-xp 00000000 08:02 347266 /lib64/libpthread-2.11.3.so
7f3f25ebd000-7f3f260bc000 ---p 00017000 08:02 347266 /lib64/libpthread-2.11.3.so
7f3f260bc000-7f3f260bd000 r--p 00016000 08:02 347266 /lib64/libpthread-2.11.3.so
7f3f260bd000-7f3f260be000 rw-p 00017000 08:02 347266 /lib64/libpthread-2.11.3.so
7f3f260be000-7f3f260c2000 rw-p 00000000 00:00 0
7f3f260c2000-7f3f2620e000 r-xp 00000000 08:02 298091 /lib64/libc-2.11.1.so
7f3f2620e000-7f3f2640d000 ---p 0014c000 08:02 298091 /lib64/libc-2.11.1.so
7f3f2640d000-7f3f26411000 r--p 0014b000 08:02 298091 /lib64/libc-2.11.1.so
7f3f26411000-7f3f26412000 rw-p 0014f000 08:02 298091 /lib64/libc-2.11.1.so
7f3f26412000-7f3f26417000 rw-p 00000000 00:00 0
7f3f26417000-7f3f2641e000 r-xp 00000000 08:02 335978 /lib64/librt-2.11.1.so
7f3f2641e000-7f3f2661d000 ---p 00007000 08:02 335978 /lib64/librt-2.11.1.so
7f3f2661d000-7f3f2661e000 r--p 00006000 08:02 335978 /lib64/librt-2.11.1.so
7f3f2661e000-7f3f2661f000 rw-p 00007000 08:02 335978 /lib64/librt-2.11.1.so
7f3f2661f000-7f3f2663d000 r-xp 00000000 08:02 260202 /lib64/ld-2.11.1.so
7f3f2682b000-7f3f2682e000 rw-p 00000000 00:00 0
7f3f26839000-7f3f2683b000 rw-p 00000000 00:00 0
7f3f2683b000-7f3f2683c000 rw-p 00000000 00:00 0
7f3f2683c000-7f3f2683d000 r--p 0001d000 08:02 260202 /lib64/ld-2.11.1.so
7f3f2683d000-7f3f2683e000 rw-p 0001e000 08:02 260202 /lib64/ld-2.11.1.so
7f3f2683e000-7f3f2683f000 rw-p 00000000 00:00 0
7fffd9ce3000-7fffd9d04000 rw-p 00000000 00:00 0 [stack]
7fffd9dff000-7fffd9e00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
following is objdump
0000000000400890 <main>:
400890: 55 push %rbp
400891: 53 push %rbx
400892: ba b6 01 00 00 mov $0x1b6,%edx
400897: be 42 02 00 00 mov $0x242,%esi
40089c: bf 9c 0a 40 00 mov $0x400a9c,%edi
4008a1: 48 83 ec 08 sub $0x8,%rsp
4008a5: e8 fe fd ff ff callq 4006a8 <shm_open#plt>
4008aa: 83 f8 ff cmp $0xffffffffffffffff,%eax
4008ad: 89 c3 mov %eax,%ebx
4008af: 0f 84 c0 00 00 00 je 400975 <main+0xe5>
4008b5: be 00 10 00 00 mov $0x1000,%esi
4008ba: 89 c7 mov %eax,%edi
4008bc: e8 37 fe ff ff callq 4006f8 <ftruncate#plt>
4008c1: 83 f8 ff cmp $0xffffffffffffffff,%eax
4008c4: 0f 84 9b 00 00 00 je 400965 <main+0xd5>
4008ca: 45 31 c9 xor %r9d,%r9d
4008cd: 31 ff xor %edi,%edi
4008cf: 41 89 d8 mov %ebx,%r8d
4008d2: b9 02 00 00 00 mov $0x2,%ecx
4008d7: ba 03 00 00 00 mov $0x3,%edx
4008dc: be 00 10 00 00 mov $0x1000,%esi
4008e1: e8 22 fe ff ff callq 400708 <mmap#plt>
4008e6: 48 83 f8 ff cmp $0xffffffffffffffff,%rax
4008ea: 48 89 c5 mov %rax,%rbp
4008ed: 0f 84 8e 00 00 00 je 400981 <main+0xf1>
4008f3: 48 8b 3d 0e 05 20 00 mov 0x20050e(%rip),%rdi # 600e08 <__TMC_END__>
4008fa: e8 b9 fd ff ff callq 4006b8 <_IO_getc#plt>
4008ff: be 00 10 00 00 mov $0x1000,%esi
400904: 48 89 ef mov %rbp,%rdi
400907: e8 dc fd ff ff callq 4006e8 <munmap#plt>
40090c: 85 c0 test %eax,%eax
40090e: 75 7a jne 40098a <main+0xfa>
400910: bf d1 0a 40 00 mov $0x400ad1,%edi
400915: e8 6e fd ff ff callq 400688 <puts#plt>
40091a: 48 8d 8d ff 0f 00 00 lea 0xfff(%rbp),%rcx
400921: 48 89 ea mov %rbp,%rdx
400924: 0f 1f 40 00 nopl 0x0(%rax)
400928: c6 02 00 movb $0x0,(%rdx)
40092b: 48 83 c2 01 add $0x1,%rdx
40092f: 48 39 ca cmp %rcx,%rdx
400932: 75 f4 jne 400928 <main+0x98>
400934: bf e9 0a 40 00 mov $0x400ae9,%edi
400939: e8 4a fd ff ff callq 400688 <puts#plt>
40093e: 48 8b 3d c3 04 20 00 mov 0x2004c3(%rip),%rdi # 600e08 <__TMC_END__>
400945: e8 6e fd ff ff callq 4006b8 <_IO_getc#plt>

Answer 1

You're invoking "undefined behavior." Anything could happen. You can't then complain that in one case you like the result more than in another case when both have undefined behavior. Just stop running invalid code.

Answer 2

Following code run successfully and message were printed without
SIGSEGV. But if I uncommented the printf before munmap, a SIGSEGV were
caught.
This prima facie startling behavior has a simple explanation. A Segmentation fault is indeed to be expected when accessing unmapped Linux memory. It's just that without the printf before munmap, the printf("Corrupting mmap memory.\n") after munmap() constitutes the program's first use of stdout, and on that first use, the Linux/GNU C library allocates a stream buffer by means of mmap(), thereby re-mapping exactly the memory page that was unmapped just before, so p[i] can access the anew mapped memory without a fault.