[LTS 9.4] CVE-2025-39682, CVE-2024-58239, CVE-2025-38571 #827
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jira VULN-131164 cve CVE-2025-38571 commit-author Olga Kornievskaia <okorniev@redhat.com> commit cc5d590 upstream-diff Resolved context conflicts from missing de4eda9 A security exploit was discovered in NFS over TLS in tls_alert_recv due to its assumption that there is valid data in the msghdr's iterator's kvec. Instead, this patch proposes the rework how control messages are setup and used by sock_recvmsg(). If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed control buffer and read in the control message such as a TLS alert. Scott found that a msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tls_alert_recv. Fixes: dea034b ("SUNRPC: Capture CMSG metadata on client-side receive") Suggested-by: Trond Myklebust <trondmy@hammerspace.com> Suggested-by: Scott Mayhew <smayhew@redhat.com> Signed-off-by: Olga Kornievskaia <okorniev@redhat.com> Link: https://lore.kernel.org/r/20250731180058.4669-3-okorniev@redhat.com Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> (cherry picked from commit cc5d590) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
jira VULN-131164 cve-bf CVE-2025-38571 commit-author Justin Worrell <jworrell@gmail.com> commit 9559d2f xs_sock_recv_cmsg was failing to call xs_sock_process_cmsg for any cmsg type other than TLS_RECORD_TYPE_ALERT (TLS_RECORD_TYPE_DATA, and other values not handled.) Based on my reading of the previous commit (cc5d590: sunrpc: fix client side handling of tls alerts), it looks like only iov_iter_revert should be conditional on TLS_RECORD_TYPE_ALERT (but that other cmsg types should still call xs_sock_process_cmsg). On my machine, I was unable to connect (over mtls) to an NFS share hosted on FreeBSD. With this patch applied, I am able to mount the share again. Fixes: cc5d590 ("sunrpc: fix client side handling of tls alerts") Signed-off-by: Justin Worrell <jworrell@gmail.com> Reviewed-and-tested-by: Scott Mayhew <smayhew@redhat.com> Link: https://lore.kernel.org/r/20250904211038.12874-3-jworrell@gmail.com Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com> (cherry picked from commit 9559d2f) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
jira VULN-136508 cve-pre CVE-2025-39682 commit-author Jakub Kicinski <kuba@kernel.org> commit ac437a5 We double count async, non-zc rx data. The previous fix was lucky because if we fully zc async_copy_bytes is 0 so we add 0. Decrypted already has all the bytes we handled, in all cases. We don't have to adjust anything, delete the erroneous line. Fixes: 4d42cd6 ("tls: rx: fix return value for async crypto") Co-developed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit ac437a5) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
jira VULN-131361 cve CVE-2024-58239 commit-author Sabrina Dubroca <sd@queasysnail.net> commit fdfbaec If we have a non-DATA record on the rx_list and another record of the same type still on the queue, we will end up merging them: - process_rx_list copies the non-DATA record - we start the loop and process the first available record since it's of the same type - we break out of the loop since the record was not DATA Just check the record type and jump to the end in case process_rx_list did some work. Fixes: 692d7b5 ("tls: Fix recvmsg() to be able to peek across multiple records") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/bd31449e43bd4b6ff546f5c51cf958c31c511deb.1708007371.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit fdfbaec) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
jira VULN-136508 cve-pre CVE-2025-39682 commit-author Sabrina Dubroca <sd@queasysnail.net> commit ec823bf If we queue 3 records: - record 1, type DATA - record 2, some other type - record 3, type DATA and do a recv(PEEK), the rx_list will contain the first two records. The next large recv will walk through the rx_list and copy data from record 1, then stop because record 2 is a different type. Since we haven't filled up our buffer, we will process the next available record. It's also DATA, so we can merge it with the current read. We shouldn't do that, since there was a record in between that we ignored. Add a flag to let process_rx_list inform tls_sw_recvmsg that it had more data available. Fixes: 692d7b5 ("tls: Fix recvmsg() to be able to peek across multiple records") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/f00c0c0afa080c60f016df1471158c1caf983c34.1708007371.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit ec823bf) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
jira VULN-136508 cve-pre CVE-2025-39682 commit-author Sabrina Dubroca <sd@queasysnail.net> commit 85eef9a process_rx_list may not copy as many bytes as we want to the userspace buffer, for example in case we hit an EFAULT during the copy. If this happens, we should only count the bytes that were actually copied, which may be 0. Subtracting async_copy_bytes is correct in both peek and !peek cases, because decrypted == async_copy_bytes + peeked for the peek case: peek is always !ZC, and we can go through either the sync or async path. In the async case, we add chunk to both decrypted and async_copy_bytes. In the sync case, we add chunk to both decrypted and peeked. I missed that in commit 6caaf10 ("tls: fix peeking with sync+async decryption"). Fixes: 4d42cd6 ("tls: rx: fix return value for async crypto") Signed-off-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/1b5a1eaab3c088a9dd5d9f1059ceecd7afe888d1.1711120964.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 85eef9a) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
jira VULN-136508 cve CVE-2025-39682 commit-author Jakub Kicinski <kuba@kernel.org> commit 62708b9 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: 84c61fe ("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> (cherry picked from commit 62708b9) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
Contributor
|
Since we fix CVEs based on priorities and not order of application, I think it's totally fine to keep the cve-pre right before the CVE. If you check the history, it looks really weird. If you are keen to keep the history as upstream, you can just use cve-pre for But yeah, I personally do not like how the history looks like at the comment. I expect cve-pre to be right before the actual cve. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[LTS 9.4]
CVE-2025-38571 VULN-131164
CVE-2025-39682 VULN-136508
CVE-2024-58239 VULN-131361
Commits
CVE-2025-38571
CVE-2025-39682 (+ CVE-2024-58239)
The fix for CVE-2025-39682 on LTS 9.4 is very similar to the fix of this CVE on LTS 9.2 174a5c5..839bab9. The multiple prerequisites allowed for clean-picked solution, while all of them were fixes anyway, so no new features were introduced. The
tls: stop recv() if initial process_rx_list gave us non-DATAcommit was needed as prerequisite for CVE-2025-39682 but had its own CVE-2024-58239.Differences from the LTS 9.2 version:
tls: rx: fix return value for async cryptobackported because it was already bacported tociqlts9_4in c85ed0c.kABI check: passed
Boot test: passed
boot-test.log
Kselftests: passed relative
Reference
kselftests–ciqlts9_4–run1.log
Patch
kselftests–ciqlts9_4-CVE-batch-19–run1.log
kselftests–ciqlts9_4-CVE-batch-19–run2.log
kselftests–ciqlts9_4-CVE-batch-19–run3.log
Comparison
The tests results for the reference and the patch are the same.