libbpf-tools/filetop,offcputime: Fix stack leaks including KASLR break - #5531
Merged
Merged
Conversation
vdasu
requested review from
brendangregg,
chenhengqi,
ekyooo and
yonghong-song
as code owners
June 25, 2026 01:59
Collaborator
|
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
force-pushed
the
filetop-offcputime-kaslr-leaks
branch
from
June 25, 2026 18:58
5f9163a to
b558bfe
Compare
Contributor
Author
|
@ekyooo I have fixed the typo and updated the commit message |
ekyooo
approved these changes
Jun 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
libbpf-tools/filetop:
get_file_path()copies the dentry name withbpf_probe_read_kernel(buf, size, dname.name)wheresize = PATH_MAX(4096). The non-_strprobe read helper copies the full size with no NUL stop, so a short name over-reads ~4 KB of adjacent kernel memory into thefile_stat.filenamemap value. I confirmed this leaks kernel.textand module pointers (e.g.kernfs_dops,ext4_file_operations) into theentriesmap, and I was able to recover the KASLR slide. Fix: usebpf_probe_read_kernel_str(), which stops at the NUL.libbpf-tools/offcputime:
handle_sched_switch()leavesstruct val_t valuninitialized, thenbpf_probe_read_kernel_str(&val.comm, ...)writes onlystrlen+1bytes before the wholevalis inserted into theinfomap. For short comms theval.commtail keeps stale BPF-stack bytes (the adjacentstart_tstimestamp), now persisted in the map. Same uninitialized-stack class as thebashreadlinefix (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 thebashreadlineprecedent. Neither changes behaviour for well-formed inputs.Checklist
libbpf-tools/filetop:,libbpf-tools/offcputime:)For new tools only — N/A (bug fixes to existing tools, no new tool)
man/man8/) with an OVERHEAD section*_example.txt)tests/python/test_tools_smoke.py