Re: [PATCH] perf test: probe_vfs_getname add do_getname() probing fallback

[sashiko-bot@kernel.org]

Sashiko AI review found 2 potential issue(s):
- [Medium] Out-of-bounds kernel memory read in `do_getname` perf probe due to unterminated string.
- [Medium] Missing user-space pointer fallback logic reduces test robustness.
--

commit 44caa018a80d8e3283b4eda7b6e0f0690afbe123
Author: Thomas Richter <tmricht@linux.ibm.com>

perf test: probe_vfs_getname add do_getname() probing fallback

This commit extends the vfs_getname perf test logic to fall back to probing
do_getname() if getname_flags() does not match. This reflects updated kernel
code where the getname_flags() implementation was changed.

> diff --git a/tools/perf/tests/shell/lib/probe_vfs_getname.sh b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> --- a/tools/perf/tests/shell/lib/probe_vfs_getname.sh
> +++ b/tools/perf/tests/shell/lib/probe_vfs_getname.sh
[ ... ]
> @@ -28,12 +30,24 @@ add_probe_vfs_getname() {
>  			line=$(perf probe -L getname_flags 2>&1 | grep -E "$result_aname_re" | sed -r "s/$result_aname_re/\1/")
>  		fi
>  
> +		if [ -z "$line" ] ; then
> +			do_getname=1
> +			result_iname_re="[[:space:]]+([[:digit:]]+)[[:space:]]+initname\(result\);"
> +			line=$(perf probe -L do_getname 2>&1 | grep -E "$result_iname_re" | sed -r "s/$result_iname_re/\1/")
> +		fi
> +
>  		if [ -z "$line" ] ; then
>  			echo "Could not find probeable line"
>  			return 2
>  		fi
>  
> -		perf probe -q       "vfs_getname=getname_flags:${line} pathname=result->name:string" || \
> +		if [ "$do_getname" -eq 1 ]
> +		then
> +			param="vfs_getname=do_getname:${line} pathname=result->iname:string"

Does this probe cause an out-of-bounds kernel memory read when the path exceeds
EMBEDDED_NAME_MAX?

If a user provides a long file path, strncpy_from_user() completely fills the
fixed-size result->iname array without appending a NUL terminator, while the
actual NUL-terminated path is dynamically allocated and pointed to by
result->name.

Because the probe explicitly instructs the kernel to read result->iname as a
NUL-terminated string, could the kprobe fetcher read past the end of the iname
array into adjacent slab memory? Should this use result->name:string instead?

> +			perf probe -q "$param" || perf probe $add_probe_verbose "$param" || return 1

Is the user-space pointer fallback missing here?

The original probe logic for getname_flags robustly handles compiler
optimizations by falling back to probing the user-space function argument
directly (pathname=filename:ustring) if reading the kernel result struct fails.

This new block for do_getname instead retries the exact same probe string, just
adding a verbose flag. Since filename remains the first argument to
do_getname(), would it be safer to include the filename:ustring fallback to
prevent the test from failing on certain toolchains?

> +			return 0
> +		fi
> +		perf probe -q "vfs_getname=getname_flags:${line} pathname=result->name:string" || \
>  		perf probe $add_probe_verbose "vfs_getname=getname_flags:${line} pathname=filename:ustring" || return 1
>  	fi
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260416125515.3481495-1-tmricht@linux.ibm.com?part=1