[PATCH 24/27] selftests/landlock: Use ASSERT for syscall failures before errno checks
sashiko-bot at kernel.org
sashiko-bot at kernel.org
Thu Oct 8 14:41:21 UTC 2026
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] selftests: ASSERT_EQ bypasses ptrace cleanup, causing test hang
--
commit f35a2df1559c7e7b062080b5d4fda3a0df26e0e3
Author: Günther Noack <gnoack3000 at gmail.com>
selftests/landlock: Use ASSERT for syscall failures before errno checks
This commit replaces EXPECT* with ASSERT* for syscall failures where
succeeding would result in an undefined errno. This ensures that the
tests abort early rather than checking undefined state.
> diff --git a/tools/testing/selftests/landlock/ptrace_test.c b/tools/testing/selftests/landlock/ptrace_test.c
> index 75f6d0dcd9375..2266e2361d923 100644
> --- a/tools/testing/selftests/landlock/ptrace_test.c
> +++ b/tools/testing/selftests/landlock/ptrace_test.c
> @@ -204,7 +204,7 @@ TEST_F(scoped_domains, trace)
> if (can_trace_parent) {
> EXPECT_EQ(0, ret);
> } else {
> - EXPECT_EQ(-1, ret);
> + ASSERT_EQ(-1, ret);
[Severity: Medium]
Will this new ASSERT_EQ bypass the ptrace cleanup on unexpected test failures?
If ptrace(PTRACE_ATTACH) unexpectedly succeeds when it is expected to fail,
it sends a SIGSTOP to the tracee.
With the change from EXPECT_EQ(-1, ret) to ASSERT_EQ(-1, ret), an unexpected
success where ret == 0 causes the test process to abort immediately.
Does this early abort bypass the subsequent if (ret == 0) block that performs
waitpid() and ptrace(PTRACE_DETACH) to clean up the stopped tracee?
Because the tracer dies without detaching or waking the tracee, the tracee
remains in a stopped state (SIGSTOP).
If the tracee is the parent test process, could the kselftest harness's
waitpid() block indefinitely, causing the entire test suite to hang instead
of cleanly reporting a failure?
> EXPECT_EQ(EPERM, errno);
> }
> if (ret == 0) {
> ASSERT_EQ(parent, waitpid(parent, &status, 0));
> ASSERT_EQ(1, WIFSTOPPED(status));
> ASSERT_EQ(0, ptrace(PTRACE_DETACH, parent, NULL, 0));
> }
[ ... ]
> @@ -276,7 +276,7 @@ TEST_F(scoped_domains, trace)
> if (can_trace_child) {
> EXPECT_EQ(0, ret);
> } else {
> - EXPECT_EQ(-1, ret);
> + ASSERT_EQ(-1, ret);
[Severity: Medium]
Similarly, if the parent's PTRACE_ATTACH on the child unexpectedly succeeds,
would the parent abort and leave the child stopped and orphaned?
> EXPECT_EQ(EPERM, errno);
> }
>
> if (ret == 0) {
> ASSERT_EQ(child, waitpid(child, &status, 0));
> ASSERT_EQ(1, WIFSTOPPED(status));
> ASSERT_EQ(0, ptrace(PTRACE_DETACH, child, NULL, 0));
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261008142604.39107-2-gnoack3000@gmail.com?part=24
More information about the Linux-security-module-archive
mailing list