From: Chuck Lever <cel@kernel.org>
To: Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>, Chuck Lever <cel@kernel.org>,
Jeff Layton <jlayton@kernel.org>, NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: linux-nfs@vger.kernel.org, netdev@vger.kernel.org
Subject: [PATCH v2 6/8] SUNRPC: reject a client-side TLS alert record that is not two octets
Date: Thu, 06 Aug 2026 16:20:21 -0400 [thread overview]
Message-ID: <20260806-svcsock-cmsg-fixes-v2-6-ef1b1fa7219a@kernel.org> (raw)
In-Reply-To: <20260806-svcsock-cmsg-fixes-v2-0-ef1b1fa7219a@kernel.org>
tls_alert_recv() reads two octets from the kvec it is handed and does
not check the length (net/handshake/alert.c). xs_sock_process_cmsg()
calls it for any alert record, and the alert[] buffer that
xs_sock_recv_cmsg() supplies carries no initializer. A one-octet alert
body leaves the description read from uninitialized stack and reported
through trace_tls_alert_recv().
The peer controls that length. Neither tls_rx_msg_size() nor
tls_rx_one_record() enforces the two-octet Alert payload. A TLS 1.3
record carrying only the inner content-type octet decrypts to a
zero-length payload. RFC 8446 Section 5.1 requires a record with an
Alert type to carry exactly one message, so any other length is
malformed. RFC 9289 Section 5 bars RPC-with-TLS from negotiating a
version below TLS 1.3, so no other alert framing applies.
Require exactly two octets before parsing and return -EACCES
otherwise. xs_stream_data_receive() already treats -EACCES as a fatal
alert and reports it to the pending tasks. Gate the path on a control
message rather than a positive count so that a zero-length record
reaches the check.
Fixes: cc5d59081fa2 ("sunrpc: fix client side handling of tls alerts")
Signed-off-by: Chuck Lever <cel@kernel.org>
---
net/sunrpc/xprtsock.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 359407aae03e..8e9d47d77e5b 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -407,9 +407,25 @@ xs_sock_recv_cmsg(struct socket *sock, unsigned int *msg_flags, int flags)
iov_iter_kvec(&msg.msg_iter, ITER_DEST, &alert_kvec, 1,
alert_kvec.iov_len);
ret = sock_recvmsg(sock, &msg, flags);
- if (ret > 0) {
- if (tls_get_record_type(sock->sk, &u.cmsg) == TLS_RECORD_TYPE_ALERT)
+ /* put_cmsg() shrinks msg_controllen, so a short one means
+ * kTLS filled in u.cmsg.
+ */
+ if (ret >= 0 && msg.msg_controllen < sizeof(u)) {
+ if (tls_get_record_type(sock->sk, &u.cmsg) ==
+ TLS_RECORD_TYPE_ALERT) {
+ /* RFC 8446 Section 5.1 requires a record with an
+ * Alert type to carry exactly one message. An alert
+ * is two octets. tls_alert_recv() reads both without
+ * checking the length. alert_kvec caps the count at
+ * two, so a longer record fills it as well. kTLS
+ * sets MSG_EOR only once the record has been
+ * drained.
+ */
+ if (ret != sizeof(alert) ||
+ !(msg.msg_flags & MSG_EOR))
+ return -EACCES;
iov_iter_revert(&msg.msg_iter, ret);
+ }
ret = xs_sock_process_cmsg(sock, &msg, msg_flags, &u.cmsg,
-EAGAIN);
}
--
2.54.0
next prev parent reply other threads:[~2026-08-06 20:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 20:20 [PATCH v2 0/8] SUNRPC: Fix TLS control record handling Chuck Lever
2026-08-06 20:20 ` [PATCH v2 1/8] SUNRPC: do not credit control-record octets to the RPC stream Chuck Lever
2026-08-06 20:20 ` [PATCH v2 2/8] SUNRPC: reject a TLS alert record that is not two octets Chuck Lever
2026-08-06 20:20 ` [PATCH v2 3/8] SUNRPC: treat every TLS error alert as fatal Chuck Lever
2026-08-06 20:20 ` [PATCH v2 4/8] SUNRPC: resume receiving after a TLS control record Chuck Lever
2026-08-06 20:20 ` [PATCH v2 5/8] SUNRPC: fold svc_tcp_sock_process_cmsg() into its only caller Chuck Lever
2026-08-06 20:20 ` Chuck Lever [this message]
2026-08-06 20:20 ` [PATCH v2 7/8] SUNRPC: treat every client-side TLS error alert as fatal Chuck Lever
2026-08-06 20:20 ` [PATCH v2 8/8] SUNRPC: fold xs_sock_process_cmsg() into its only caller Chuck Lever
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=20260806-svcsock-cmsg-fixes-v2-6-ef1b1fa7219a@kernel.org \
--to=cel@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=anna@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=netdev@vger.kernel.org \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
--cc=trondmy@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.