A long-running service may keep credentials, session material, or decrypted state in memory while still relying on core images for crash diagnosis. Disabling core generation for the entire process removes diagnostic state along with sensitive state. Linux provides a narrower control: madvise() with MADV_DONTDUMP marks selected mappings so the kernel omits them from a core image.
This mechanism changes core-dump inclusion policy for an address range. It does not make the bytes inaccessible to the process, encrypt them, erase them, or create a general barrier against process inspection. Its security value is specific to one data-exposure path: memory captured through the kernel core-dump mechanism.
The flag belongs to virtual memory areas
madvise(addr, length, MADV_DONTDUMP) applies advice to pages covering the supplied range. Linux records the resulting dump policy on virtual memory areas, the kernel structures that describe contiguous mappings with common properties.
The address must be page aligned, and the affected range is interpreted at page granularity. A request that cuts through an existing mapping can cause the kernel to split virtual memory areas so that the selected region carries a different dump policy.
long page = sysconf(_SC_PAGESIZE);
void *p = mmap(NULL, page, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (p == MAP_FAILED)
handle_error();
if (madvise(p, page, MADV_DONTDUMP) == -1)
handle_error();The mapping remains readable and writable according to its normal protection bits. MADV_DONTDUMP is not a substitute for mprotect(), access control, or memory isolation.
Core generation consults mapping policy
A core image represents selected process state at a termination point. Linux has several controls that influence whether a core is produced and which mappings it contains. The process dumpable attribute, resource limits, kernel configuration, core routing, and per-process coredump_filter all participate at different layers.
MADV_DONTDUMP operates at the mapping layer. When the kernel constructs a core image, mappings carrying this flag are excluded even when broader core-dump policy would otherwise include their mapping class.
That makes the flag useful for small regions whose disclosure cost differs from the rest of the address space. Diagnostic mappings can remain eligible while a buffer holding sensitive material is omitted.
The inverse operation is MADV_DODUMP. Applying it to a region removes the MADV_DONTDUMP exclusion and returns that mapping to the normal core-selection rules. The transition is therefore reversible; applications must treat later advice calls as part of the security state.
Exclusion is not erasure
Omission from a core image says nothing about the lifetime of the bytes in live memory. The process can still read the region. Other threads sharing the same address space can still access it according to the mapping protections. A permitted debugger or another interface with sufficient process-inspection authority may still access live memory.
The flag also does not scrub physical pages when a mapping is released. Sensitive-data lifecycle controls require separate handling when erasure properties matter. MADV_DONTDUMP only controls inclusion in core output.
This distinction prevents an overly broad claim that a DONTDUMP region is secret. The mechanism reduces one persistence and disclosure channel; confidentiality still depends on process boundaries, ptrace-related policy, credentials, capabilities, Linux Security Module decisions, swap and storage policy, and application behavior.
Fork carries the mapping state into the child
Virtual memory area attributes are inherited across fork() along with the mappings to which they apply. A child therefore starts with the corresponding dump exclusion on inherited regions.
That inheritance can be desirable when a parent stores sensitive state before creating workers. It can also create a policy assumption that needs explicit tracking: if a child later remaps data, creates a new buffer, or applies MADV_DODUMP, the original exclusion does not automatically cover every future location containing related bytes.
execve() replaces the process memory image, so a new program establishes its own mappings and dump policy. Applications cannot treat a pre-exec DONTDUMP decision as a persistent property of a logical secret independent of its storage location.
coredump_filter and DONTDUMP solve different selection problems
Linux exposes /proc/self/coredump_filter to select classes of mappings, such as anonymous private or file-backed mappings, for core output. That control is process-wide and category-oriented.
MADV_DONTDUMP is range-oriented. It can carve an exception out of a mapping class that remains generally eligible. A service can retain anonymous private memory in core images while excluding a designated anonymous buffer.
The two mechanisms therefore compose rather than replace each other. coredump_filter establishes broad inclusion classes; per-mapping advice can remove specific regions. Operational tooling that changes process-wide core policy does not turn a DONTDUMP region into ordinary dumpable memory unless the mapping flag itself is changed.
Core routing remains a separate trust boundary
Excluding sensitive mappings reduces the data sent into a core image, but the remaining image can still contain credentials, identifiers, request data, file contents, stack fragments, or application state from other mappings. Core storage and transport remain security-sensitive.
On systems that pipe core data to a collector, the collector becomes part of the crash-data trust boundary. File permissions, retention, compression, upload, and support workflows can extend that boundary beyond the host where the process failed.
Per-region exclusion is strongest when paired with deliberate data placement. If sensitive values are copied across general heaps, stacks, caches, and temporary buffers, marking one allocation cannot account for every replica. A dedicated mapping gives the kernel a precise region on which to enforce the exclusion.
The useful boundary is narrow and inspectable
MADV_DONTDUMP provides a concrete kernel-enforced property: selected mappings are omitted from Linux core images while they retain the flag. The property is narrower than memory secrecy and narrower than process non-dumpability.
That narrowness is operationally valuable. A service can preserve most crash diagnostics while keeping designated mappings outside the core artifact. The resulting guarantee depends on page-granular placement, continued presence of the mapping flag, and control of copies outside the protected region. Core exclusion is therefore a property of a mapping, not a durable label attached to the data itself.