From 8291637a6e82d0e70b94dc71b33843f006ef6630 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 24 Aug 2025 11:12:23 +0200 Subject: [PATCH] 6.1-stable patches added patches: tls-fix-handling-of-zero-length-records-on-the-rx_list.patch --- queue-6.1/series | 1 + ...f-zero-length-records-on-the-rx_list.patch | 65 +++++++++++++++++++ 2 files changed, 66 insertions(+) create mode 100644 queue-6.1/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 9caadd41bb..318a111095 100644 --- 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 index 0000000000..204bd69296 --- /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 +Date: Tue, 19 Aug 2025 19:19:51 -0700 +Subject: tls: fix handling of zero-length records on the rx_list + +From: Jakub Kicinski + +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 +Reported-by: Billy Jheng Bing-Jhong +Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser") +Reviewed-by: Sabrina Dubroca +Link: https://patch.msgid.link/20250820021952.143068-1-kuba@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + 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); -- 2.47.3