summaryrefslogtreecommitdiff
path: root/Documentation/gpu/intel-display/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorArnaldo Carvalho de Melo <acme@redhat.com>2026-06-07 22:37:55 -0300
committerArnaldo Carvalho de Melo <acme@redhat.com>2026-06-10 18:56:01 -0300
commit31d596054550f793508abe7dd593853ece47d428 (patch)
treed37c299fba5c0289be49bbd04f322b8a1552bb92 /Documentation/gpu/intel-display/git@git.tavy.me:linux.git
parentb6bb3b005dcdd960b8e0b7f9d6869132b3de08d5 (diff)
perf tools: Fix thread__set_comm_from_proc() on empty comm file
thread__set_comm_from_proc() calls procfs__read_str() then strips the trailing newline via comm[sz - 1] = '\0'. procfs__read_str() allocates the buffer before reading, so on an empty /proc/pid/comm (reachable during late exit teardown) it returns success with sz = 0 and an unterminated heap buffer. The sz - 1 underflow was the original sashiko finding: it writes a null byte before the allocation. But even with a sz > 0 guard on the newline strip, the unterminated buffer would still be passed to thread__set_comm() which calls strlen() — an unbounded heap read. Fix by treating sz == 0 as failure: free the buffer and return -1. This is consistent with pmu.c's perf_pmu__parse_scale/unit which already treat len == 0 from filename__read_str as an error. Fixes: 2f3027ac28bf6bc3 ("perf thread: Introduce method to set comm from /proc/pid/self") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Diffstat (limited to 'Documentation/gpu/intel-display/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions