6.16-stable patches

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

diff --git a/queue-6.16/series b/queue-6.16/series
index e389461e3f154b1e198ab7f91e224bc961575fc9..429465083e379bda2b736c0ca643f5fff7e2a932 100644 (file)
--- a/queue-6.16/series
+++ b/queue-6.16/series
@@ -330,3 +330,4 @@ tracing-remove-unneeded-goto-out-logic.patch
 tracing-limit-access-to-parser-buffer-when-trace_get_user-failed.patch
 ovl-use-i_mutex_parent-when-locking-parent-in-ovl_create_temp.patch
 pci-dwc-ensure-that-dw_pcie_wait_for_link-waits-100-ms-after-link-up.patch
+tls-fix-handling-of-zero-length-records-on-the-rx_list.patch

diff --git a/queue-6.16/tls-fix-handling-of-zero-length-records-on-the-rx_list.patch b/queue-6.16/tls-fix-handling-of-zero-length-records-on-the-rx_list.patch
new file mode 100644 (file)
index 0000000..492834b
--- /dev/null
+++ b/queue-6.16/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
+@@ -1808,6 +1808,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)
+ {
+@@ -2051,8 +2054,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);