Inspect /proc/kcore Safely Before You Touch GDB

/proc/kcore looks like an ordinary file right up until you cat it, and that single habit can hang a box or spray kernel state across your terminal. This guide follows proc_kcore(5) from Linux man-pages 6.7, installed here as package version 6.7-2. You will finish with a safe way to identify what the file is, check its metadata without dumping memory, and prepare a GDB command for examining kernel data structures once you have the matching unstripped kernel image.

Allow about fifteen minutes for the read-only checks. A real kernel investigation takes longer and needs a matching vmlinux, GDB, suitable privileges, and a reason to inspect live kernel state. Do not treat this pseudo-file as an ordinary log or data file.

1. Confirm the local contract

Read the installed manual before touching the file. This is an ordinary command and does not need elevated privileges:

$ man 5 proc_kcore

The relevant contract is short. /proc/kcore represents the system's physical memory in ELF core-file format. The manual says GDB can use it with an unstripped kernel binary, normally /usr/src/linux/vmlinux, to examine current kernel data structures. It also documents a file length equal to physical RAM plus 4 KiB.

$ getconf PAGESIZE
4096
$ dpkg-query -W -f='${Package} ${Version}\n' manpages
manpages 6.7-2

The package version is distribution-specific. If your output differs, keep the version beside any investigation notes: procfs behaviour and permissions belong to the running kernel as well as the manual package.

2. Inspect metadata, not memory

Start with stat. It asks the kernel for file metadata and does not copy the contents of /proc/kcore into your terminal or a new file:

$ stat -c 'path=%n type=%F size=%s mode=%A owner=%U:%G' /proc/kcore
path=/proc/kcore type=regular file size=140737471594496 mode=-r-------- owner=root:root

On this host the entry is root-owned and only readable by root. The reported type is a procfs representation, not a normal disk file. The huge size is also a reminder that a file-like interface does not mean a cheap, useful cp operation exists. Do not infer that the number is safe to allocate or copy merely because stat reports it.

Check the path and permissions independently if you are recording evidence:

$ command -v stat
/usr/bin/stat
$ ls -l /proc/kcore
-r-------- 1 root root 140737471594496 Sep 26 12:00 /proc/kcore

The timestamp, size and exact formatting vary. What matters is that the path exists, its owner and mode are visible, and no command has attempted to read its contents.

3. Avoid the tempting commands

• Do not run cat /proc/kcore. It requests a memory-backed interface and can produce unreadable output or consume resources.
• Do not pipe it through strings. Same problem: it can expose sensitive kernel state for no diagnostic gain.
• Do not redirect it to a file as a first test. A shell redirection can truncate an existing destination before the reader even reports an error, leaving you with a ruined file and a large partial dump.

If you accidentally started a foreground read, stop it with Ctrl-C. Then check the destination explicitly rather than deleting files by pattern:

$ test -e /path/to/accidental-output && stat -c '%n %s bytes' /path/to/accidental-output
/path/to/accidental-output 0 bytes
$ rm -- /path/to/accidental-output

4. Find a matching unstripped kernel image

GDB needs symbols and layout information from an unstripped kernel binary. The manual names /usr/src/linux/vmlinux as the usual path, but distributions often keep images elsewhere or do not install one at all. Look for the documented path first:

$ test -r /usr/src/linux/vmlinux && echo 'readable vmlinux found' || echo 'no readable vmlinux at the documented path'
no readable vmlinux at the documented path

Do not substitute /boot/vmlinuz-... just because the name looks close: a compressed boot image is not automatically the unstripped ELF file needed for useful symbol lookup. Obtain the exact unstripped image from the build or debugging artefacts for the running kernel, and keep its provenance with your notes. Record the running kernel release before choosing an image:

$ uname -r
6.8.0-example

Replace the example output with your host's value. The image should correspond to that kernel build, not merely to a similar release number. If the image is missing or stripped, stop at the metadata checks: there is no useful GDB session to recover by guessing.

5. Open the live core interface only for a reason

Reading live kernel memory is security-sensitive. It can reveal credentials, keys, pointers, process data and other information ordinary users cannot access. Use a maintenance window or an approved debugging session, understand who can see the terminal and output, and avoid recording arbitrary memory in tickets or shell history. The following command normally requires elevated privileges because /proc/kcore is commonly root-readable:

# gdb /path/to/matching/unstripped/vmlinux /proc/kcore

Use an explicit path to the verified image. Do not copy this command unchanged unless that path exists and matches the running kernel. Inside GDB, examine only the kernel symbol or structure relevant to the incident: the exact expression depends on the kernel version, configuration and debugging question, so proc_kcore(5) gives you no universal command to paste at the prompt.

$ command -v gdb
/usr/bin/gdb
$ test -r /path/to/matching/unstripped/vmlinux && echo 'kernel image readable' || echo 'kernel image missing or unreadable'
kernel image missing or unreadable

This example deliberately stops before GDB. Running the debugger as root does not repair a missing or mismatched image, and it does not make an unsafe memory dump safe.

6. Clean up without changing the system

Closing GDB ends the inspection session, but it does not change kernel memory, unload modules or alter persistent configuration. If you created a temporary command file or captured output, identify it by its exact path and follow your retention policy. Do not remove debugging artefacts that another investigator still needs.

There is no configuration rollback for the metadata workflow, because it changes nothing. If you used GDB, record the image path, kernel release, time, investigator and commands used. That makes a later session reproducible without turning broad memory output into a permanent secret store.

Done means

• Manual read. You read the installed proc_kcore(5) and recorded the local man-pages version.
• Metadata only. You inspected /proc/kcore with stat and ls, without reading its contents.
• Format understood. You know the file is an ELF core-format view of physical memory, not a normal backup file.
• Risky commands avoided. You avoided cat, cp and broad text extraction against the pseudo-file.
• Image verified. You confirmed the running kernel release and located a matching unstripped vmlinux before considering GDB.
• Access controlled. Any elevated inspection is authorised, narrowly scoped and documented.