Why mmap Shared Memory Is More Dangerous Than malloc – Risks Explained

Hello, I am Xiao Feng, author of the bestseller "Secrets of the Computer Bottom Layer". Today we discuss a interview question: why mmap shared memory is more dangerous than malloc, a topic that clearly distinguishes the two.

In system programming, memory management is a core issue that developers must face. C/C++ developers commonly allocate memory using malloc (heap memory) or mmap (shared memory/file mapping).

Although both provide memory allocation capabilities, from a system‑risk perspective mmap shared memory is considerably more dangerous; a small mistake can lead to severe security vulnerabilities or stability problems.

mmap shared memory can cause other processes to crash

mmap allows multiple processes to read and write the same physical memory, meaning an error in one process can directly affect other processes' data, potentially causing crashes. For example, an out‑of‑bounds write in process A may crash process B or corrupt its data.

In short, shared memory breaks process‑level memory isolation.

By contrast, using malloc , such an out‑of‑bounds write only affects the current process and does not propagate across processes, because memory allocated by malloc exists solely within the allocating process and is naturally isolated.

Permission risks of mmap

mmap can set memory read/write/execute permissions (e.g., PROT_EXEC ). If configured incorrectly, attackers can exploit this for code‑injection attacks such as executing malicious code after a buffer overflow.

<code>void *mem_start = mmap(NULL, 4096, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);</code>

Assume a network service allocates a memory region with mmap for handling client requests and mistakenly grants executable permission ( PROT_EXEC ). The program copies user‑provided data into this region without length checks. An attacker can craft an oversized packet containing malicious shellcode and overflow data that overwrites the return address or function pointer to point to mem_start . When the program jumps to that address, the shellcode executes, potentially achieving privilege escalation or a reverse shell. Since mem_start is marked executable, the OS does not block execution. Using malloc for heap allocation avoids this issue because the memory is not executable.

Multithreading and synchronization risks

When using mmap shared memory, multiple processes or threads must synchronize access via semaphores, locks, etc.; otherwise data races or dirty reads can occur, affecting all processes sharing the memory.

malloc itself is thread‑safe (via global locks or thread‑local caches), but developers still need to manage concurrent access to the allocated region. Without proper locking, race conditions can still happen, yet the impact remains limited to the current process, unlike mmap where the impact spreads across processes.