Inspect Kernel Memory Safely with /proc/kcore and GDB

You will finish with a safe way to identify what /proc/kcore is, check its metadata without dumping memory, and prepare a GDB command for examining kernel data structures when you have the matching unstripped kernel image. This guide follows proc_kcore(5) from Linux man-pages 6.7, installed here as package version 6.7-2.

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.

Checkpoint: confirm the page size and installed manual package, so a copied result has enough context:

$ 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 because 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 very large size is also a reminder that a file-like interface does not mean that 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. The useful checks are 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, send it through strings, or redirect it to a file as a first test. These commands request a memory-backed interface and can produce unreadable output, consume resources, expose sensitive kernel state, or leave a large partial file. A shell redirection can also truncate an existing destination before the reader reports an error.

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

The final command is destructive. Run it only when the path is exactly the unwanted output. If the file might contain useful evidence, preserve it according to your incident or debugging procedure instead of removing it.

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 its 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 that 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 GDB expression depends on the kernel version, configuration and debugging question, so proc_kcore(5) does not provide a universal command to paste at the GDB prompt.

Checkpoint: before escalating, prove that the prerequisites are present without opening the core:

$ 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.