memfd_secret(2)

🌸 NAME 🌸

okay so bestie, meet memfd_secret(2) — the syscall that makes an anonymous RAM-based file so you can get at secret memory regions 💅✨. Like, it literally creates an anonymous RAM-based file that gives you access to secret memory regions. Iconic behavior only.

---

📚 LIBRARY 📚

Standard C library (libc, -lc) 🫶

---

✨ SYNOPSIS ✨

#include <sys/syscall.h>      /* Definition of SYS_* constants */
#include <unistd.h>

int syscall(SYS_memfd_secret, unsigned int flags);

bestie no cap — glibc does not give you a wrapper for memfd_secret(), so you gotta go through syscall(2). That's just the way it is 😭

---

🦋 DESCRIPTION 🦋

So memfd_secret() creates an anonymous RAM-based file and hands you back a file descriptor pointing at it. The whole point of this file is that it lets you make and access memory regions with stronger protection than your usual RAM-based files and anonymous memory mappings. And the second every open reference to the file gets closed, it's automatically released — no cleanup era needed 💅 The initial size of the file is 0, so right after the call you should set the file size with ftruncate(2).

The memory areas backing the file you made with memfd_secret(2)? Only visible to the processes that hold the file descriptor. The memory region gets yanked out of the kernel page tables, and only the page tables of the processes holding the file descriptor map the corresponding physical memory. Which means — and this is the wild part — the pages in the region can't be accessed by the kernel itself, so like, pointers to the region can't be passed to system calls. The kernel is literally not invited 🚫🫶

These values may be bitwise ORed in flags to control what memfd_secret() does:

• FD_CLOEXEC — sets the close-on-exec flag on the new file descriptor, which makes the region get removed from the process on execve(2). Go read the description of the O_CLOEXEC flag in open(2) if you want the lore 🌈

As its return value, memfd_secret() returns a new file descriptor that refers to an anonymous file. This fd is opened for both reading and writing (O_RDWR), and O_LARGEFILE is set for the file descriptor. Both. At once. Multitasking queen 👑

About fork(2) and execve(2) — the usual semantics apply to the fd that memfd_secret() made 🧚 A copy of the file descriptor gets inherited by the child produced by fork(2), and it refers to the same file. The file descriptor is preserved across execve(2), unless the close-on-exec flag has been set.

The memory region is locked into memory the same way it works with mlock(2), so it will never get written into swap, and hibernation is inhibited for as long as any memfd_secret() descriptions exist 😴❌ However, the implementation of memfd_secret() will not try to populate the whole range during the mmap(2) call that attaches the region into the process's address space — instead, the pages only actually get allocated as they are faulted in. Lazy allocation but make it secure ✨ The amount of memory allowed for memory mappings of the file descriptor obeys the same rules as mlock(2) and cannot exceed RLIMIT_MEMLOCK.

---

🎀 RETURN VALUE 🎀

On success, memfd_secret() returns a new file descriptor 🥳 On error, -1 is returned and errno is set to indicate the error. Rude but standard.

---

💀 ERRORS 💀

• EINVAL — flags included unknown bits. Like, who are you even.
• EMFILE — the per-process limit on the number of open file descriptors has been reached. Too many fds bestie, close some 🫠
• ENFILE — the system-wide limit on the total number of open files has been reached. Not just you, it's everyone.
• ENOMEM — there was insufficient memory to create a new anonymous file. The math wasn't mathing 😭
• ENOSYS — memfd_secret() is not implemented on this architecture, or has not been enabled on the kernel command-line with secretmem_enable=1.

---

📜 STANDARDS 📜

Linux. periodt 💅

---

🕰️ HISTORY 🕰️

Linux 5.14 ✨

Before Linux 6.5, memfd_secret() was disabled by default and only available if the system administrator turned it on using the "secretmem.enable=y" kernel parameter. So yeah, it used to be invite-only 🎟️

---

👑 NOTES 👑

The memfd_secret() system call is designed to let a user-space process create a range of memory that is inaccessible to anybody else — kernel included. There is no 100% guarantee that the kernel won't be able to access memory ranges backed by memfd_secret() in any circumstances, but nevertheless, it's much harder to exfiltrate data from these regions. Not perfect, but it's giving protection 💅

memfd_secret() provides the following protections:

• Enhanced protection (in conjunction with all the other in-kernel attack prevention systems) against ROP attacks 🛡️ The absence of any in-kernel primitive for accessing memory backed by memfd_secret() means that a one-gadget ROP attack can't work to perform data exfiltration. The attacker would need to find enough ROP gadgets to reconstruct the missing page table entries, which significantly increases the difficulty of the attack, especially when other protections like the kernel stack size limit and address space layout randomization are in place. Good luck with that ig 😌
• Prevent cross-process user-space memory exposures 🚫 Once a region for a memfd_secret() memory mapping is allocated, the user can't accidentally pass it into the kernel to be transmitted somewhere. The memory pages in this region cannot be accessed via the direct map, and they are disallowed in get_user_pages. Slay.
• Harden against exploited kernel flaws 💪 In order to access memory areas backed by memfd_secret(), a kernel-side attack would need to either walk the page tables and create new ones, or spawn a new privileged user-space process to perform secrets exfiltration using ptrace(2). That's a lot of work, bestie.

To prevent potential data leaks of memory regions backed by memfd_secret() from a hibernation image, hibernation is prevented when there are active memfd_secret() users 😴🚫

---

🔗 SEE ALSO 🔗

fcntl(2), ftruncate(2), mlock(2), memfd_create(2), mmap(2), setrlimit(2)

---

okay that's the whole page bestie, go forth and be secretive 🕵️♀️💖 this was brought to you by Linux man-pages 6.20, dated 2026-07-18, and yeah that's memfd_secret(2) — no cap, stay locked (in memory) 💅✨