From: Danish Khateeb <danishkhateeb03@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jirislaby@kernel.org>, Shuah Khan <shuah@kernel.org>,
Abhinav Saxena <xandfury@gmail.com>, Kees Cook <kees@kernel.org>,
linux-serial@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org,
Danish Khateeb <danishkhateeb03@gmail.com>
Subject: [PATCH] selftests/tty: tiocsti: expect the privileged parent to succeed
Date: Tue, 20 Oct 2026 21:01:06 -0500 [thread overview]
Message-ID: <20261021020106.94174-1-danishkhateeb03@gmail.com> (raw)
The FD passing tests open a pty in a child process, which may drop its
privileges first, and pass the FD to the parent, which always has
CAP_SYS_ADMIN. The child's own TIOCSTI is checked against
.expected_success, and so is the parent's TIOCSTI on the passed FD.
TIOCSTI checks the capabilities of the caller, not those of the process
that opened the tty, so the parent always succeeds. Where the child has
dropped its privileges and is expected to fail, the parent's check fails
instead:
# tty_tiocsti_test.c:620:test:Expected result (0) == variant->expected_success (-5)
# tty_tiocsti_test.c:622:test:FD passing: expected error -5, got 0
...
# FAILED: 13 / 16 tests passed.
fdpass_pty_restricted_nocap, fdpass_nopty_permissive_nocap and
fdpass_nopty_restricted_nocap have failed like this since the test was
added in v6.19. The FD passing tests are skipped without CAP_SYS_ADMIN,
so these three fail whenever they run.
Checking the opener's credentials instead was proposed together with
the first version of this test, and the reviewers did not see the
current behaviour as a problem: a process with CAP_SYS_ADMIN is
responsible for what it does with the FDs it accepts.
Expect the parent's TIOCSTI to succeed, and drop the log message that
calls this a security concern.
Fixes: 7553f5173ec3 ("selftests/tty: add TIOCSTI test suite")
Link: https://lore.kernel.org/all/2025062327-shady-broadcast-237d@gregkh/
Link: https://lore.kernel.org/all/20250624.3bb75890f0b0@gnoack.org/
Signed-off-by: Danish Khateeb <danishkhateeb03@gmail.com>
---
Notes:
Tested under virtme-ng as root with KASAN/lockdep kernels, next-20261020
and next-20260930, two runs each:
before: pass:13 fail:3 (the three fdpass_*_nocap variants above)
after: pass:16 fail:0
An LLM was used to help with this patch.
tools/testing/selftests/tty/tty_tiocsti_test.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/tty/tty_tiocsti_test.c b/tools/testing/selftests/tty/tty_tiocsti_test.c
index 5e767e6cb3ef..411fb459cbce 100644
--- a/tools/testing/selftests/tty/tty_tiocsti_test.c
+++ b/tools/testing/selftests/tty/tty_tiocsti_test.c
@@ -610,17 +610,14 @@ TEST_F(tiocsti, test)
/* SECURITY TEST: Try TIOCSTI with FD opened by child */
int result = test_tiocsti_injection(_metadata, received_fd);
- /* Log security concern if demonstrated */
- if (result == 0 && !variant->requires_cap) {
- TH_LOG("*** SECURITY CONCERN DEMONSTRATED ***");
- TH_LOG("Privileged parent can use TIOCSTI on FD from unprivileged child");
- TH_LOG("This shows current process credentials are used, not opener credentials");
- }
-
- EXPECT_EQ(result, variant->expected_success)
+ /*
+ * TIOCSTI checks the capabilities of the caller, not those of
+ * the process that opened the tty, so the privileged parent
+ * succeeds even where the child failed.
+ */
+ EXPECT_EQ(result, 0)
{
- TH_LOG("FD passing: expected error %d, got %d",
- variant->expected_success, result);
+ TH_LOG("FD passing: expected success, got %d", result);
}
/* Signal child completion */
base-commit: 1184f87e2790e8af9be3116f608d2e86b4792d7d
--
2.56.0
reply other threads:[~2026-10-21 2:01 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261021020106.94174-1-danishkhateeb03@gmail.com \
--to=danishkhateeb03@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=xandfury@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®