All of lore.kernel.org
 help / color / mirror / Atom feed
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 0/2] tls: fix plaintext sk_msg ring over-fill in tls_sw_sendmsg_splice()
Date: Sun, 26 Jul 2026 19:55:54 +0900	[thread overview]
Message-ID: <20260726105556.2719227-1-ppoo1220@gmail.com> (raw)

An unprivileged local user can oops the kernel by splicing into a kTLS
socket whose open record already has a full plaintext scatterlist ring.

sk_msg_page_add() has no fullness check of its own and
tls_sw_sendmsg_splice() only tests sk_msg_full() at the bottom of its
do-while loop, so a page is always added before the ring is checked.  That
first add writes the reserved slot and wraps sg.end onto sg.start;
sk_msg_iter_dist() then returns 0, sk_msg_full() reports the full ring as
empty, and the loop keeps overwriting live entries while sg.size grows.
Pushing the resulting record drives the AEAD with a cryptlen larger than
the walkable scatterlist, so the walk runs past the end-marked entry and
dereferences the NULL returned by sg_next().

The ring is left full and unpushed across a syscall by the copy path,
which does not set full_record when the fragment it adds is the one that
exactly fills the ring.

No capabilities, namespaces, io_uring, nftables or BPF are involved; a
plain loopback TCP socket with the "tls" ULP attached is enough.
Reproduced as an ordinary user (uid 1000) on stock production configs --
CONFIG_TLS=y, no KASAN, no LOCKDEP, no fault injection -- on 7.2.0-rc4 and
on 6.12.96.  Present since v6.5.

Patch 1 evaluates the loop condition before the first sk_msg_page_add()
instead of after it.  Patch 2 adds a regression test: it oopses an
unpatched kernel and passes with patch 1 applied (924/924 for the whole
tls suite, with CONFIG_CRYPTO_CHACHA20POLY1305, CONFIG_CRYPTO_SM4 and
CONFIG_CRYPTO_ARIA enabled so every cipher variant runs).

I found this with AI assistance, so per
Documentation/process/security-bugs.rst I am treating it as public and
posting here rather than sending it to security@kernel.org.  For the same
reason I am not posting the standalone reproducer; I can send it privately
if that would be useful.

chanyoung (2):
  tls: don't over-fill the plaintext sk_msg ring in
    tls_sw_sendmsg_splice()
  selftests: tls: add a test for splicing onto a full plaintext record

 net/tls/tls_sw.c                  |  4 +--
 tools/testing/selftests/net/tls.c | 52 +++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+), 2 deletions(-)

-- 
2.43.0


             reply	other threads:[~2026-07-26 10:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-26 10:55 chanyoung [this message]
2026-07-26 10:55 ` [PATCH net 1/2] tls: don't over-fill the plaintext sk_msg ring in tls_sw_sendmsg_splice() chanyoung
2026-07-27 10:30   ` Sabrina Dubroca
2026-07-27 12:58     ` chanyoung
2026-07-26 10:55 ` [PATCH net 2/2] selftests: tls: add a test for splicing onto a full plaintext record chanyoung
2026-07-27 11:55   ` Sabrina Dubroca
2026-07-27 12:59     ` chanyoung

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-1-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 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.