Choose Which Memory Enters a Linux Core Dump

You will inspect and change the memory-selection mask for one Linux process, then verify the value without creating a core file. The setting lives at /proc/PID/coredump_filter. Allow about ten minutes. You need a shell and a process whose proc entry you are allowed to read; changing another process may also require the privileges appropriate to that process.

This guide uses the installed proc_pid_coredump_filter(5) from Linux man-pages 6.7, package version 6.7-2. The test machine is running kernel 6.8.0-139-generic. The manpage points to core(5) for the details of producing a dump, while the filter itself has existed since Linux 2.6.23.

1. Read the current filter

Start with your own shell process. /proc/self follows the process running the command, so this is read-only and avoids guessing a PID:

$ cat /proc/self/coredump_filter
00000033

The exact value is host-specific. On this machine the kernel reports 00000033, which is the usual default mask 0x33. The leading zeroes are formatting, not extra bits. Check the file directly before relying on any documented default, because a kernel command-line setting can change the default.

Checkpoint: you have a hexadecimal value and have not changed a process or produced a dump.

2. Decode the useful bits

The value is a bitmask. A set bit includes that memory type in a core dump; a clear bit excludes it. Here are the bits in coredump_filter:

Bit	Hex value	Memory selected
0	`0x01`	Anonymous private memory
1	`0x02`	Anonymous shared memory
2	`0x04`	File-backed private memory
3	`0x08`	File-backed shared memory
4	`0x10`	ELF header pages in file-backed private mappings, effective when bit 2 is clear
5	`0x20`	Private hugetlb memory
6	`0x40`	Shared hugetlb memory
7	`0x80`	Private DAX memory
8	`0x100`	Shared DAX memory

For example, 0x33 sets bits 0, 1, 4 and 5. That selects anonymous private and shared memory, ELF header pages in eligible file-backed private mappings, and private hugetlb memory. It does not select ordinary file-backed private or shared mappings. MMIO pages are never dumped, and vDSO pages are always dumped regardless of this mask.

3. Set a filter before launching a program

Set the value in the shell that will launch the target. The child inherits the mask from its parent, so this is the most useful placement for a one-off test:

$ printf '0x7\n' > /proc/self/coredump_filter
$ cat /proc/self/coredump_filter
00000007
$ /path/to/program

0x7 enables bits 0, 1 and 2: anonymous private, anonymous shared and file-backed private memory. Replace /path/to/program with the real executable. Writing to /proc/self changes the shell process, and therefore the setting inherited by its later child. It does not alter the kernel-wide default or rewrite an existing process's memory.

Use an explicit value rather than trying to edit the file with a text editor. The file is a proc control interface, not a persistent configuration file. The change ends with that process tree unless the program itself changes its setting or a parent establishes another inherited value.

Checkpoint: verify the mask immediately after writing it. If it still shows the old value, stop and inspect the error rather than assuming the dump will use the new selection.

4. Change a running process carefully

If the program is already running and you have permission to control it, replace PID with its decimal process ID:

$ printf '0x31\n' > /proc/PID/coredump_filter
$ cat /proc/PID/coredump_filter
00000031

0x31 keeps bits 0, 4 and 5. This example is the kernel documentation's pattern for excluding the shared-memory classes represented by bits 1 and 3 while retaining the other selected categories. It is an example of bit arithmetic, not a universal safe setting for every application.

Writing another process's proc file is a security-sensitive operation. Do not use sudo automatically: first confirm that the PID is correct, that it is the process you intend to affect, and that the resulting core may contain sensitive data. A process can contain credentials, tokens and private application data even when you are collecting the dump for debugging.

There is no separate undo command. Restore the value you recorded in step 1, or terminate the test process and start a fresh one with the intended parent setting:

$ printf '0x33\n' > /proc/PID/coredump_filter
$ cat /proc/PID/coredump_filter
00000033

5. Do not confuse filtering with enabling dumps

A successful write only chooses memory segments if a core dump is produced. It does not enable core dumps, raise RLIMIT_CORE, change /proc/sys/kernel/core_pattern, bypass PR_SET_DUMPABLE, or create a destination directory. A dump can still be absent because of resource limits, permissions, program properties, kernel configuration or a system service that captures cores elsewhere.

Conversely, a core dump may omit memory for reasons outside this mask. An application can mark mappings with MADV_DONTDUMP, and the kernel's fixed MMIO and vDSO rules still apply. Check the core-dump policy separately before diagnosing a missing file as a filter problem.

Do not test by deliberately crashing a production service. If you need to prove the complete dump path, use a disposable process and an approved test directory, record the active limits and core pattern first, and treat the resulting file as sensitive. Reading or copying it can expose the same secrets as the crashed process.

Done means

You read the target process's current hexadecimal mask before changing it.
You selected bits by memory type and verified the written value.
You set the value before launch when inheritance was the intended behaviour.
You treated changes to another PID and any core file as security-sensitive.
You kept core-dump enablement, limits and storage policy as separate checks.