I'm running Arch linux on my laptop, which is kernel 3.12.9 right now. Something has changed about the way the kernel maps in a dynamically-linked executable and I can't figure it out. Here's the example:

% /usr/bin/cat /proc/self/maps
00400000-0040b000 r-xp 00000000 08:02 1186756             /usr/bin/cat
0060a000-0060b000 r--p 0000a000 08:02 1186756             /usr/bin/cat
0060b000-0060c000 rw-p 0000b000 08:02 1186756             /usr/bin/cat
00d6c000-00d8d000 rw-p 00000000 00:00 0                   [heap]
7f29b3485000-7f29b3623000 r-xp 00000000 08:02 1182988     /usr/lib/libc-2.19.so

My question is: what is the third mapping from /usr/bin/cat?

Based on readelf -l /usr/bin/cat, there's a loadable segment of 0x1f8 bytes that should map at 0x400000. There's a loadable segment of 0xae10 bytes at 0x60ae10. Those two pieces of file correspond to the 00400000-0040b000 mapping, and the 0060a000-0060b000 mapping. But the third mapping, which claims to be at a file offset of 0xb000 bytes, doesn't seem to correspond to any Elf64_Phdr. In fact, the elf header only has 2 PT_LOAD segments.

I read through fs/binfm_elf.c in the kernel 3.13.2 source code, and I don't see that the kernel maps in anything other than PT_LOAD segments. If I run strace -o trace.out /usr/bin/cat /proc/self/maps, I don't see any mmap() calls that would map in a piece of /usr/bin/cat, so that 3rd piece is mapped in by the kernel.

I ran the same command (cat /proc/self/maps) on a RHEL server that was running kernel 2.6.18 + RH patches. That only shows 2 pieces of /usr/bin/cat mapped into memory, so this might be new with kernel 3.x.

  • Just confirming your findings, I noticed the same differences on CentOS 5 (2.6.18-238.19.1.el5). However on CentOS 6 (2.6.32-358.11.1.el6.x86_64) it too shows the 3 segments. When reading this I also had the thought if this was something to do with SELinux or security in some way.
    – slm
    Feb 11, 2014 at 8:20
  • 1
    Isn't that code (.text), read-only data (.rodata), and read-write global data (.data)? Feb 11, 2014 at 18:20
  • @Gilles - if you do readelf -h /usr/bin/cat, you can see that the .text and .rodata sections end up in the first LOAD segment. .data and .bss sections end up in the second LOAD segment. This 3rd mapped segment is something else.
    – user732
    Feb 11, 2014 at 18:44
  • 1
    @psusi I'm talking about segment in ELF header, not a memory region. The second LOAD segment splits into two memory regions with r--p and rw-p execute permissions respectively. The question is why does it happen.
    – newbie
    Dec 12, 2014 at 17:32
  • 1
    @psusi Take a look at this paste. As we can see there are five sections (18-22) which are mapped to the memory region 08054000-08055000 [r--p]. The weird thing is that these sections have WA flags and should be writeable.
    – newbie
    Dec 15, 2014 at 21:20

2 Answers 2


I finally figured this out. The kernel does map only 2 segments. The third piece is a portion of one of the two loaded by the kernel. The run time linker, the program named in the INTERP pheader, which is /usr/lib/ld-2.24.so for me right now, changes the permissions on the mappings using mprotect() so that there are read/write global variables, read-only global variables, and a read/execute text segment. You can see this happen using strace, but it's easy to miss, as it's only a single mprotect() call.

It wasn't a kernel change that caused this, it was a GNU lib C change.


hi i had the same confuse as you, i had dig the internet and find this, i think this is the answer to your confuse too. link: https://stackoverflow.com/questions/33756119/relationship-between-vma-and-elf-segments

for shrot:

00400000-0040b000 r-xp 00000000 08:02 1186756             /usr/bin/cat
**use for store text code and const varibles**

0060a000-0060b000 r--p 0000a000 08:02 1186756             /usr/bin/cat
**use for GNU_RELRO relocated info**

0060b000-0060c000 rw-p 0000b000 08:02 1186756             /usr/bin/cat
use for bss data segment

hope this useful

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy