How can a Linux process execute a binary that has no name in any filesystem?

## The mechanism On Linux, a file does not need a name. A file is an inode plus data; a *name* is a directory entry pointing at that inode. The kernel offers a way to create an inode with data and **no directory entry at all**: an anonymous, memory-backed file, obtained through `memfd_create`, which returns a file descriptor and nothing else. Bytes written to that descriptor live in memory (charged to the process, like any anonymous memory), not on any block device. That descriptor can then be executed. `execveat` with an empty path and the flag that means `use this descriptor as the program` starts it directly; equivalently, the descriptor is visible to the process through `/proc` and can be executed by that pseudo-path. Either way the kernel loads the image from an object that no directory ever pointed to. ## What the running process looks like The image path of the running process resolves to an anonymous object with a `(deleted)` marker. That is the same marker you get from a completely different and much older trick - write the payload to a normal directory, execute it, then unlink it while it is still running. Both end up nameless; only one of them ever touched a filesystem. ```text # process A - payload written to a writable directory, executed, then unlinked /proc/8811/exe -> /var/tmp/.cache1 (deleted) # process B - payload never had a directory entry at any point /proc/9024/exe -> /memfd:job (deleted) ``` The distinction is worth internalising because `(deleted)` alone establishes only that the running image has no directory entry now - not that it never had one. ## Why an operator bothers **Mount options stop mattering.** A common hardening step on an application server is to make every directory the service account can write to non-executable. That control acts on a mounted filesystem. An anonymous memory object is not on one, so the restriction does not reach it. This is a large part of why the technique exists at all. **Nothing is left as a program.** There is no path to open, no image on disk to hash or submit anywhere, and no file whose creation or modification time records the moment the operator arrived. **It fits the position.** Code already running as the application's service account, with no privilege beyond it, can do all of this: creating an anonymous file and executing it needs no elevation. ## What it costs the operator **Nothing survives the process.** The bytes exist only while a descriptor is open. Exit, restart or reboot and they are gone - there is no durable copy anywhere, because the whole point was not to make one. **The payload must be delivered every time.** Each execution requires the full bytes to arrive again, which means either a fetch over the network or a re-run of the exploit that got the operator here. **It is memory, and memory is accounted.** A large payload held this way shows up as memory attributed to a process that has no reason to hold it. **No stealth about privilege.** The technique conceals the image, not the process. The process exists, runs as a known account, and does whatever it does under that account's limits. ## The economics that make it a good trade anyway For a commodity crew mass-exploiting one flaw in an internet-facing application, all of those costs are cheap and the benefit is real. Re-entry costs one request. Persistence costs work and plants something durable that an owner can find. So the correct read of a memory-only, nothing-planted payload is frequently not *the operator failed to persist* but *the operator chose not to*, because the way in is still open and is cheaper than the alternative. ## Not to be confused with This is about the operator's **own** process running a nameless image. Getting code into somebody else's live process to inherit its identity and its normal destinations is a different technique with a different cost profile. And a payload carried as data for an installed interpreter is a third shape: there the executable never exists at all, not even anonymously - the runtime is the executable.