Re: [PATCH 09/15] perf scripts: Add perf-stuck, to tell where a running perf is stuck

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] perf/scripts: privilege escalation via unscoped pgrep in perf-stuck.sh
- [Medium] perf/scripts: gdb script crashes on NULL dwarf_diename()
--

commit 31fcb1c1d74aa548fa6dd4ca2fccfd9cd7dfd922
Author: Arnaldo Carvalho de Melo <acme@redhat.com>

perf scripts: Add perf-stuck, to tell where a running perf is stuck

This commit adds the perf-stuck.sh and perf-stuck.gdb scripts to sample a
running process and determine if it is stuck in an unbounded loop or
recursing. The script checks /proc/<pid> entries at a fixed interval and can
optionally use gdb to dump the DIE chain being walked if the process is stuck
in a DWARF type chasing loop.

> diff --git a/tools/perf/scripts/perf-stuck.gdb b/tools/perf/scripts/perf-stuck.gdb
> new file mode 100644
> index 0000000000000..53e9019828b6e
> --- /dev/null
> +++ b/tools/perf/scripts/perf-stuck.gdb
> @@ -0,0 +1,104 @@
[ ... ]
> +define perf-die-chain
> +  if $argc < 2
> +    printf "usage: perf-die-chain <function> <die variable> [iterations]\n"
> +  else
> +    frame function $arg0
> +    if $argc == 3
> +      set $perf_die_chain_n = $arg2
> +    else
> +      set $perf_die_chain_n = 10
> +    end
> +    set $perf_die_chain_head = $pc
> +    set $perf_die_chain_i = 0
> +    while $perf_die_chain_i < $perf_die_chain_n
> +      printf "chain[%d] die=%p addr=%p cu=%p off=0x%lx tag=%d name=%s\n", $perf_die_chain_i, $arg1, $arg1->addr, $arg1->cu, ((Dwarf_Off) dwarf_dieoffset($arg1)), ((int) dwarf_tag($arg1)), ((char *) dwarf_diename($arg1))

[Severity: Medium]
Since pointer type DIEs lack a DW_AT_name attribute, dwarf_diename() will
return NULL for them. Will GDB's printf with the %s format specifier evaluating
a 0x0 pointer result in a "Cannot access memory at address 0x0" error, aborting
the GDB batch script?

> +      until *$perf_die_chain_head
> +      set $perf_die_chain_i = $perf_die_chain_i + 1
> +    end
> +  end
> +end
[ ... ]
> diff --git a/tools/perf/scripts/perf-stuck.sh b/tools/perf/scripts/perf-stuck.sh
> new file mode 100755
> index 0000000000000..70e59192b1d96
> --- /dev/null
> +++ b/tools/perf/scripts/perf-stuck.sh
> @@ -0,0 +1,194 @@
[ ... ]
> +if [[ "$1" =~ ^[0-9]+$ ]]; then
> +	pid=$1
> +else
> +	pid=$(pgrep -x "$1" | head -1)

[Severity: High]
Since pgrep -x searches across all users, could an unprivileged user create a
malicious process matching the target name (e.g. 'perf'), causing this to
resolve to the attacker's PID instead of the legitimate root process if an
administrator runs this script?

> +	[ -n "$pid" ] || { echo "no process named '$1'"; exit 1; }
> +fi
[ ... ]
> +	if [ -n "$use_gdb" ] && [ -z "$gdb_done" ] && [ "$stuck" -ge 2 ]; then
> +		gdb_log=$(mktemp /tmp/perf-stuck-gdb.XXXXXX)
> +		gdb -p "$pid" -batch -x "$gdb_cmds" -ex bt \

[Severity: High]
If the PID was resolved to an attacker-controlled process, does invoking gdb
as root on it allow local privilege escalation by executing arbitrary code via
malicious DWARF debug info or GDB auto-load scripts?

> +		    -ex 'perf-die-chain-all' -ex perf-dso -ex detach > "$gdb_log" 2>&1
> +		gdb_done=1
> +		echo "... gdb output of $pid in $gdb_log"
> +	fi
> +
> +	prev_cpu=$cpu

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917155528.62607-1-acme@kernel.org?part=9