From: sashiko-bot@kernel.org
To: wen.yang@linux.dev
Cc: linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v5 9/9] selftests/ftrace: Walk up to find test.d/functions when a subdirectory is passed
Date: Wed, 19 Aug 2026 18:31:33 +0000 [thread overview]
Message-ID: <20260819183133.5EE301F000E9@smtp.kernel.org> (raw)
In-Reply-To: <7808194405719fd0ae7b0bcf4301c5902eb31929.1787161646.git.wen.yang@linux.dev>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Local Privilege Escalation via untrusted directory traversal when implicitly sourcing test.d/functions.
- [Medium] Infinite loop in directory traversal when testing top-level directories due to POSIX 'dirname' behavior with double slashes.
--
--- Patch [9]: [PATCH v5 9/9] selftests/ftrace: Walk up to find test.d/functions when a subdirectory is passed ---
commit 982c65a7f93c6d254f86b734c29fd401b0e3707a
Author: Wen Yang <wen.yang@linux.dev>
selftests/ftrace: Walk up to find test.d/functions when a subdirectory is passed
When a test directory that does not itself contain test.d/functions is
passed to ftracetest (e.g. verification/test.d/tlob/), ftracetest fell
back to its own functions file and lost the rv-specific check_requires
handling for ':monitor' and ':reactor' requirements.
> diff --git a/tools/testing/selftests/ftrace/ftracetest b/tools/testing/selftests/ftrace/ftracetest
> index 0a56bf209f6c0..3ba929820dd2c 100755
> --- a/tools/testing/selftests/ftrace/ftracetest
> +++ b/tools/testing/selftests/ftrace/ftracetest
> @@ -159,9 +159,20 @@ parse_opts() { # opts
> if [ -n "$OPT_TEST_CASES" ]; then
> TEST_CASES=$OPT_TEST_CASES
> fi
> - if [ -n "$OPT_TEST_DIR" -a -f "$OPT_TEST_DIR"/test.d/functions ]; then
> - TOP_DIR=$OPT_TEST_DIR
> - TEST_DIR=$TOP_DIR/test.d
> + if [ -n "$OPT_TEST_DIR" ]; then
> + # Walk up from OPT_TEST_DIR to find the nearest ancestor that contains
> + # test.d/functions. This allows a monitor subdirectory (e.g.
> + # verification/test.d/tlob/) to be passed directly without placing a
> + # dummy functions shim in each new subdirectory.
> + dir=$OPT_TEST_DIR
> + while [ "$dir" != "/" ]; do
[Severity: Medium]
Can this loop run indefinitely if a user passes a directory directly under
the root, like /tmp?
If the path is formatted as //tmp, GNU dirname preserves double leading
slashes because it treats them as POSIX UNC paths. If dir starts as //tmp,
dirname "$dir" evaluates to //, and the loop condition [ "$dir" != "/" ]
will evaluate to true infinitely, causing the test script to hang.
> + if [ -f "$dir/test.d/functions" ]; then
> + TOP_DIR=$dir
> + TEST_DIR=$TOP_DIR/test.d
> + break
> + fi
[Severity: High]
Could this directory traversal lead to arbitrary code execution if the path
walks back through a world-writable directory?
If ftracetest is run as root on a trusted directory inside a path like
/tmp/legitimate_tests/, the loop will traverse up to /tmp and search for
/tmp/test.d/functions.
An unprivileged attacker could preemptively plant a malicious script at
that location. The script would then be found, and since the ftracetest
script later sources this file, it would execute the attacker's code with
root privileges.
> + dir=$(dirname "$dir")
> + done
> + fi
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1787161646.git.wen.yang@linux.dev?part=9
prev parent reply other threads:[~2026-08-19 18:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 18:15 [PATCH v5 0/9] rv: Add task latency over budget RV monitor wen.yang
2026-08-19 18:15 ` [PATCH v5 1/9] rv: Introduce DA_MON_ALLOCATION_STRATEGY wen.yang
2026-08-19 18:30 ` sashiko-bot
2026-08-19 18:15 ` [PATCH v5 2/9] rv: Add generic uprobe infrastructure for RV monitors wen.yang
2026-08-19 18:27 ` sashiko-bot
2026-08-19 18:15 ` [PATCH v5 3/9] rv: Add tlob model DOT file wen.yang
2026-08-19 18:25 ` sashiko-bot
2026-08-19 18:15 ` [PATCH v5 4/9] rv: Fix ha_invariant_passed_ns silent bypass of invariant check wen.yang
2026-08-19 18:32 ` sashiko-bot
2026-08-19 18:15 ` [PATCH v5 5/9] rv: Make da_monitor_reset_hook and EVENT_NONE_LBL overridable wen.yang
2026-08-19 18:30 ` sashiko-bot
2026-08-19 18:15 ` [PATCH v5 6/9] rv: Add tlob hybrid automaton monitor wen.yang
2026-08-19 18:34 ` sashiko-bot
2026-08-19 18:15 ` [PATCH v5 7/9] rv: Add KUnit tests for the tlob monitor wen.yang
2026-08-19 18:24 ` sashiko-bot
2026-08-19 18:15 ` [PATCH v5 8/9] selftests/verification: Add tlob selftests wen.yang
2026-08-19 18:27 ` sashiko-bot
2026-08-19 18:15 ` [PATCH v5 9/9] selftests/ftrace: Walk up to find test.d/functions when a subdirectory is passed wen.yang
2026-08-19 18:31 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260819183133.5EE301F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=wen.yang@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.