6.1-stable patches

added patches:
	tls-fix-handling-of-zero-length-records-on-the-rx_list.patch

diff --git a/queue-6.1/series b/queue-6.1/series
index 9caadd41bb9b2efb5eab330250750bd2013e82a4..318a1110955f13ce910364c31b4a795d6a38cefa 100644 (file)
--- a/queue-6.1/series
+++ b/queue-6.1/series
@@ -442,3 +442,4 @@ drm-amd-display-don-t-overclock-dce-6-by-15.patch
 selftests-mptcp-pm-check-flush-doesn-t-reset-limits.patch
 wifi-mac80211-avoid-lockdep-checking-when-removing-deflink.patch
 wifi-mac80211-check-basic-rates-validity-in-sta_link_apply_parameters.patch
+tls-fix-handling-of-zero-length-records-on-the-rx_list.patch

diff --git a/queue-6.1/tls-fix-handling-of-zero-length-records-on-the-rx_list.patch b/queue-6.1/tls-fix-handling-of-zero-length-records-on-the-rx_list.patch
new file mode 100644 (file)
index 0000000..204bd69
--- /dev/null
+++ b/queue-6.1/tls-fix-handling-of-zero-length-records-on-the-rx_list.patch
@@ -0,0 +1,65 @@
+From 62708b9452f8eb77513115b17c4f8d1a22ebf843 Mon Sep 17 00:00:00 2001
+From: Jakub Kicinski <kuba@kernel.org>
+Date: Tue, 19 Aug 2025 19:19:51 -0700
+Subject: tls: fix handling of zero-length records on the rx_list
+
+From: Jakub Kicinski <kuba@kernel.org>
+
+commit 62708b9452f8eb77513115b17c4f8d1a22ebf843 upstream.
+
+Each recvmsg() call must process either
+ - only contiguous DATA records (any number of them)
+ - one non-DATA record
+
+If the next record has different type than what has already been
+processed we break out of the main processing loop. If the record
+has already been decrypted (which may be the case for TLS 1.3 where
+we don't know type until decryption) we queue the pending record
+to the rx_list. Next recvmsg() will pick it up from there.
+
+Queuing the skb to rx_list after zero-copy decrypt is not possible,
+since in that case we decrypted directly to the user space buffer,
+and we don't have an skb to queue (darg.skb points to the ciphertext
+skb for access to metadata like length).
+
+Only data records are allowed zero-copy, and we break the processing
+loop after each non-data record. So we should never zero-copy and
+then find out that the record type has changed. The corner case
+we missed is when the initial record comes from rx_list, and it's
+zero length.
+
+Reported-by: Muhammad Alifa Ramdhan <ramdhan@starlabs.sg>
+Reported-by: Billy Jheng Bing-Jhong <billy@starlabs.sg>
+Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser")
+Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
+Link: https://patch.msgid.link/20250820021952.143068-1-kuba@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/tls/tls_sw.c |    7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/net/tls/tls_sw.c
++++ b/net/tls/tls_sw.c
+@@ -1864,6 +1864,9 @@ int decrypt_skb(struct sock *sk, struct
+       return tls_decrypt_sg(sk, NULL, sgout, &darg);
+ }
+ 
++/* All records returned from a recvmsg() call must have the same type.
++ * 0 is not a valid content type. Use it as "no type reported, yet".
++ */
+ static int tls_record_content_type(struct msghdr *msg, struct tls_msg *tlm,
+                                  u8 *control)
+ {
+@@ -2107,8 +2110,10 @@ int tls_sw_recvmsg(struct sock *sk,
+       if (err < 0)
+               goto end;
+ 
++      /* process_rx_list() will set @control if it processed any records */
+       copied = err;
+-      if (len <= copied || (copied && control != TLS_RECORD_TYPE_DATA) || rx_more)
++      if (len <= copied || rx_more ||
++          (control && control != TLS_RECORD_TYPE_DATA))
+               goto end;
+ 
+       target = sock_rcvlowat(sk, flags & MSG_WAITALL, len);