Skip to content

libbpf-tools/filetop,offcputime: Fix stack leaks including KASLR break - #5531

Merged
ekyooo merged 1 commit into
iovisor:masterfrom
vdasu:filetop-offcputime-kaslr-leaks
Jul 2, 2026
Merged

libbpf-tools/filetop,offcputime: Fix stack leaks including KASLR break#5531
ekyooo merged 1 commit into
iovisor:masterfrom
vdasu:filetop-offcputime-kaslr-leaks

Conversation

@vdasu

@vdasu vdasu commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

Description

libbpf-tools/filetop: get_file_path() copies the dentry name with bpf_probe_read_kernel(buf, size, dname.name) where size = PATH_MAX (4096). The non-_str probe read helper copies the full size with no NUL stop, so a short name over-reads ~4 KB of adjacent kernel memory into the file_stat.filename map value. I confirmed this leaks kernel .text and module pointers (e.g. kernfs_dops, ext4_file_operations) into the entries map, and I was able to recover the KASLR slide. Fix: use bpf_probe_read_kernel_str(), which stops at the NUL.

libbpf-tools/offcputime: handle_sched_switch() leaves struct val_t val uninitialized, then bpf_probe_read_kernel_str(&val.comm, ...) writes only strlen+1 bytes before the whole val is inserted into the info map. For short comms the val.comm tail keeps stale BPF-stack bytes (the adjacent start_ts timestamp), now persisted in the map. Same uninitialized-stack class as the bashreadline fix (c2d8f9b). Fix: zero-initialize the struct (struct val_t *valp, val = {};).

Why this approach

Minimal and consistent with the tree: bpf_probe_read_kernel_str() is the idiomatic kernel-string read (e.g. hardirqs), and zeroing the struct follows the bashreadline precedent. Neither changes behaviour for well-formed inputs.


Checklist

  • Commit prefix matches changed area (libbpf-tools/filetop:, libbpf-tools/offcputime:)
  • Commit body explains why this change is needed

For new tools only — N/A (bug fixes to existing tools, no new tool)

  • Explains why this tool is needed and what existing tools cannot cover this use case
  • Includes at least one real production use case
  • Man page (man/man8/) with an OVERHEAD section
  • Example output file (*_example.txt)
  • README.md entry added
  • Smoke test added to tests/python/test_tools_smoke.py

@ekyooo

ekyooo commented Jun 25, 2026

Copy link
Copy Markdown
Collaborator
  1. The two checklist items are about the commit message. Please improve it, including the typo.
  2. Please squash the two commits.

filetop: get_file_path() copies the dentry name with the non-string
helper bpf_probe_read_kernel(buf, size, dname.name), where size is the
full PATH_MAX (4096) destination length. That helper copies size bytes
with no NUL stop, so for a short name it over-reads ~4 KB of adjacent
kernel memory into the file_stat.filename map value, leaking kernel
.text and module pointers (dentry/inode/file operation tables) that are
enough to defeat KASLR. Use bpf_probe_read_kernel_str(), which stops at
the NUL.

offcputime: handle_sched_switch() leaves struct val_t val uninitialized,
then bpf_probe_read_kernel_str(&val.comm, ...) writes only strlen+1
bytes before the whole val is inserted into the info map. For short comm
names the val.comm tail keeps stale BPF stack bytes (the adjacent
start_ts timestamp), now persisted in the map and readable by any map
consumer. Zero-initialize val. This is the same uninitialized-stack
disclosure class fixed in bashreadline (commit c2d8f9b).
@vdasu
vdasu force-pushed the filetop-offcputime-kaslr-leaks branch from 5f9163a to b558bfe Compare June 25, 2026 18:58
@vdasu vdasu changed the title libbpf-tools/filetop,offcputime: Fix stack leaks including KALSR break libbpf-tools/filetop,offcputime: Fix stack leaks including KASLR break Jun 25, 2026
@vdasu

vdasu commented Jun 25, 2026

Copy link
Copy Markdown
Contributor Author

@ekyooo I have fixed the typo and updated the commit message

@ekyooo
ekyooo merged commit d3b8def into iovisor:master Jul 2, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants