memfd_create() creates an anonymous file backed by memory. A process can write code into it, seal its properties, and execute it without placing a conventional named binary on disk. That behavior is useful for runtimes and legitimate packaging. It also creates a blind spot for controls that only inspect paths and file hashes.
The executable bit is a policy choice
Linux added MFD_EXEC and MFD_NOEXEC_SEAL to make executable memory files explicit. The kernel documentation says that MFD_NOEXEC_SEAL creates a non-executable memfd, sets F_SEAL_EXEC, and prevents the executable bit from being added later. MFD_EXEC requests an executable file. If neither flag is supplied, behavior depends on the pid namespace setting vm.memfd_noexec.
The setting has three scopes. A value of 0 treats an unmarked memfd as executable. A value of 1 applies the noexec seal by default while still allowing an explicit MFD_EXEC. A value of 2 rejects a call that omits the noexec seal. The value is inherited by child pid namespaces and the kernel uses the most restrictive setting in the hierarchy.
Containers should make this setting visible in the runtime configuration and test it inside the workload namespace. A host-wide number is not enough. A container that needs an older runtime may still have a different effective policy from the host.
File scanning cannot see an unnamed object
An endpoint control that watches /tmp or a writable application directory can see a dropped file and compute its hash. A memfd has no durable path in that directory. A process can pass a descriptor to a child or use it as the target of an execution operation. Visibility requires process and syscall telemetry, not only filesystem inventory.
Record memfd_create calls, the calling process, the requested flags, the pid namespace, and subsequent execution or memory mapping. Do not collect the bytes of every memfd in production. A bounded allowlist of known runtimes and an alert on unexpected exec-capable descriptors will produce more useful evidence.
Prefer the least capable mode
Applications that do not execute from memfds should request MFD_NOEXEC_SEAL or run under a namespace policy that supplies it by default. Build pipelines should test under the same kernel and namespace policy as production. A test that passes on a workstation with vm.memfd_noexec=0 does not prove that a hardened node will accept the same call.
Use seccomp or a mandatory access control profile to restrict who can create executable memfds. Apply a deny rule to application processes that should never need one. Keep an exception for the runtime components that genuinely require it, and review that exception when the runtime version changes.
Measure the gap
Inventory hosts by kernel version, pid namespace policy, and container runtime. Add a probe that checks the effective setting from inside a representative container. Alert when the value changes or when a workload begins creating executable memfds after a deployment.
The control is not a ban on memfds. It is a record of when an anonymous memory object becomes executable and which namespace allowed that transition. That record closes a gap that path-based scanning cannot address.