From: chanyoung <ppoo1220@gmail.com>
To: netdev@vger.kernel.org
Cc: John Fastabend <john.fastabend@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
Sabrina Dubroca <sd@queasysnail.net>,
David Howells <dhowells@redhat.com>,
Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org, chanyoung <ppoo1220@gmail.com>
Subject: [PATCH net 2/2] selftests: tls: add a test for splicing onto a full plaintext record
Date: Sun, 26 Jul 2026 19:55:56 +0900 [thread overview]
Message-ID: <20260726105556.2719227-3-ppoo1220@gmail.com> (raw)
In-Reply-To: <20260726105556.2719227-1-ppoo1220@gmail.com>
Splicing into an open record whose plaintext scatterlist ring was already
full used to wrap the ring's end index onto its start. sk_msg_full() then
reported the full ring as empty, so the loop kept overwriting live entries
while sg.size grew, and pushing the record ran the AEAD scatterwalk off the
end of the scatterlist.
Reaching that state needs the ring to be left full and unpushed across a
syscall, which the copy path does when the fragment it adds is the one that
fills the ring. The test therefore fills the ring with splices, adds one
byte with MSG_MORE, splices some more, and only then pushes the record.
MAX_SKB_FRAGS is configurable, so rather than hardcoding the number of
fragments needed to fill the ring, sweep it over the plausible range so the
one-byte send lands exactly on a full ring whatever the kernel was built
with.
On an unpatched kernel this oopses in the AEAD walk; with the preceding
patch applied the whole tls selftest suite passes.
Signed-off-by: Chanyoung Park <ppoo1220@gmail.com>
---
tools/testing/selftests/net/tls.c | 52 +++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/tools/testing/selftests/net/tls.c b/tools/testing/selftests/net/tls.c
index cbdd3ea28b9..d2666884ea8 100644
--- a/tools/testing/selftests/net/tls.c
+++ b/tools/testing/selftests/net/tls.c
@@ -835,6 +835,58 @@ TEST_F(tls, send_and_splice)
EXPECT_EQ(memcmp(mem_send, mem_recv, send_len), 0);
}
+/* Splicing into an open record whose plaintext scatterlist ring is already
+ * full used to wrap the ring's end index onto its start, after which
+ * sk_msg_full() reported the full ring as empty: further pages overwrote
+ * live entries and sg.size desynced from the walkable scatterlist, which
+ * oopsed in the AEAD walk once the record was pushed. The ring is left
+ * full and unpushed by the copy path, which does not push the record when
+ * the fragment it adds is the one that fills the ring.
+ */
+TEST_F(tls, splice_onto_full_record)
+{
+ int frag_len = 100, extra = 4;
+ char mem_send[5000];
+ char mem_recv[5000];
+ int nfrags, i, total;
+ int p[2];
+
+ memrnd(mem_send, sizeof(mem_send));
+
+ /* MAX_SKB_FRAGS is configurable (17 by default), so sweep the
+ * plausible range to land the one-byte send exactly on a full ring
+ * whatever this kernel was built with.
+ */
+ for (nfrags = 12; nfrags <= 45; nfrags++) {
+ total = (nfrags + extra) * frag_len + 2;
+
+ for (i = 0; i < nfrags; i++) {
+ ASSERT_GE(pipe(p), 0);
+ EXPECT_EQ(write(p[1], mem_send, frag_len), frag_len);
+ EXPECT_EQ(splice(p[0], NULL, self->fd, NULL, frag_len,
+ SPLICE_F_MORE), frag_len);
+ close(p[0]);
+ close(p[1]);
+ }
+
+ EXPECT_EQ(send(self->fd, mem_send, 1, MSG_MORE), 1);
+
+ for (i = 0; i < extra; i++) {
+ ASSERT_GE(pipe(p), 0);
+ EXPECT_EQ(write(p[1], mem_send, frag_len), frag_len);
+ EXPECT_EQ(splice(p[0], NULL, self->fd, NULL, frag_len,
+ SPLICE_F_MORE), frag_len);
+ close(p[0]);
+ close(p[1]);
+ }
+
+ EXPECT_EQ(send(self->fd, mem_send, 1, 0), 1);
+
+ EXPECT_EQ(recv(self->cfd, mem_recv, total, MSG_WAITALL), total);
+ EXPECT_EQ(memcmp(mem_send, mem_recv, frag_len), 0);
+ }
+}
+
TEST_F(tls, splice_to_pipe)
{
int send_len = TLS_PAYLOAD_MAX_LEN;
--
2.43.0
prev parent reply other threads:[~2026-07-26 10:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-26 10:55 [PATCH net 0/2] tls: fix plaintext sk_msg ring over-fill in tls_sw_sendmsg_splice() chanyoung
2026-07-26 10:55 ` [PATCH net 1/2] tls: don't over-fill the plaintext sk_msg ring " chanyoung
2026-07-26 10:55 ` chanyoung [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=20260726105556.2719227-3-ppoo1220@gmail.com \
--to=ppoo1220@gmail.com \
--cc=dhowells@redhat.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=sd@queasysnail.net \
--cc=shuah@kernel.org \
/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