[lts92] Many VULNs 2025-11-04 #670
Open
+226
−170
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-131259 cve CVE-2025-38556 commit-author Alan Stern <[email protected]> commit a6b87bf Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that. Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does. Signed-off-by: Alan Stern <[email protected]> Reported-by: [email protected] Closes: https://lore.kernel.org/linux-usb/[email protected]/ Tested-by: [email protected] Fixes: dde5845 ("[PATCH] Generic HID layer - code split") Cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]> (cherry picked from commit a6b87bf) Signed-off-by: Brett Mastbergen <[email protected]>
jira VULN-131360 cve CVE-2024-58239 commit-author Sabrina Dubroca <[email protected]> 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 <[email protected]> Link: https://lore.kernel.org/r/bd31449e43bd4b6ff546f5c51cf958c31c511deb.1708007371.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit fdfbaec) Signed-off-by: Brett Mastbergen <[email protected]>
jira VULN-136507 cve-pre CVE-2025-39682 commit-author Jakub Kicinski <[email protected]> commit 4d42cd6 Gaurav reports that TLS Rx is broken with async crypto accelerators. The commit under fixes missed updating the retval byte counting logic when updating how records are stored. Even tho both before and after the change 'decrypted' was updated inside the main loop, it was completely overwritten when processing the async completions. Now that the rx_list only holds non-zero-copy records we need to add, not overwrite. Reported-and-bisected-by: Gaurav Jain <[email protected]> Fixes: cbbdee9 ("tls: rx: async: don't put async zc on the list") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217064 Tested-by: Gaurav Jain <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 4d42cd6) Signed-off-by: Brett Mastbergen <[email protected]>
jira VULN-136507 cve-pre CVE-2025-39682 commit-author Jakub Kicinski <[email protected]> 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 <[email protected]> Signed-off-by: Sabrina Dubroca <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> (cherry picked from commit ac437a5) Signed-off-by: Brett Mastbergen <[email protected]>
jira VULN-136507 cve-pre CVE-2025-39682 commit-author Sabrina Dubroca <[email protected]> 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 <[email protected]> Link: https://lore.kernel.org/r/f00c0c0afa080c60f016df1471158c1caf983c34.1708007371.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit ec823bf) Signed-off-by: Brett Mastbergen <[email protected]>
jira VULN-136507 cve-pre CVE-2025-39682 commit-author Sabrina Dubroca <[email protected]> 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 <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/1b5a1eaab3c088a9dd5d9f1059ceecd7afe888d1.1711120964.git.sd@queasysnail.net Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 85eef9a) Signed-off-by: Brett Mastbergen <[email protected]>
jira VULN-136507 cve CVE-2025-39682 commit-author Jakub Kicinski <[email protected]> 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 <[email protected]> Reported-by: Billy Jheng Bing-Jhong <[email protected]> Fixes: 84c61fe ("tls: rx: do not use the standard strparser") Reviewed-by: Sabrina Dubroca <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 62708b9) Signed-off-by: Brett Mastbergen <[email protected]>
jira VULN-154755 cve CVE-2022-50341 commit-author Paulo Alcantara <[email protected]> commit f7f291e When running xfstests against Azure the following oops occurred on an arm64 system Unable to handle kernel write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : __memcpy+0x40/0x230 lr : scatterwalk_copychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000 Call trace: __memcpy+0x40/0x230 scatterwalk_map_and_copy+0x98/0x100 crypto_ccm_encrypt+0x150/0x180 crypto_aead_encrypt+0x2c/0x40 crypt_message+0x750/0x880 smb3_init_transform_rq+0x298/0x340 smb_send_rqst.part.11+0xd8/0x180 smb_send_rqst+0x3c/0x100 compound_send_recv+0x534/0xbc0 smb2_query_info_compound+0x32c/0x440 smb2_set_ea+0x438/0x4c0 cifs_xattr_set+0x5d4/0x7c0 This is because in scatterwalk_copychunks(), we attempted to write to a buffer (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining 8 (x2) bytes ended up crossing a page boundary. To simply fix it, we could just pass @sign kmalloc'd from crypt_message() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in smb_rqst::rq_iov... Instead, let's map the correct pages and offsets from vmalloc buffers as well in cifs_sg_set_buf() and then avoiding such oopses. Signed-off-by: Paulo Alcantara (SUSE) <[email protected]> Cc: [email protected] Signed-off-by: Steve French <[email protected]> (cherry picked from commit f7f291e) Signed-off-by: Brett Mastbergen <[email protected]> # Conflicts: # fs/cifs/cifsglob.h
jira VULN-154755 cve-bf CVE-2022-50341 commit-author Yang Li <[email protected]> commit d74f4a3 ./fs/cifs/cifsglob.h: linux/scatterlist.h is included more than once. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3459 Fixes: f7f291e ("cifs: fix oops during encryption") Reported-by: Abaci Robot <[email protected]> Signed-off-by: Yang Li <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit d74f4a3) Signed-off-by: Brett Mastbergen <[email protected]>
Simplifies the workflow to use the reusable workflow defined in main branch. This reduces duplication and makes the workflow easier to maintain across multiple branches. The workflow was renamed because it now includes validation over and above just checking for upstream fixes
🔍 Interdiff Analysis
diff -u b/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
--- b/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -66,8 +66,12 @@
static u32 s32ton(__s32 value, unsigned int n)
{
- s32 a = value >> (n - 1);
+ s32 a;
+ if (!value || !n)
+ return 0;
+
+ a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
return value & ((1 << n) - 1);
@@ -1338,12 +1338,7 @@
static u32 s32ton(__s32 value, unsigned n)
{
- s32 a;
-
- if (!value || !n)
- return 0;
-
- a = value >> (n - 1);
+ s32 a = value >> (n - 1);
if (a && a != -1)
return value < 0 ? 1 << (n - 1) : (1 << (n - 1)) - 1;
return value & ((1 << n) - 1);
reverted:
--- b/fs/cifs/cifsencrypt.c
+++ a/fs/cifs/cifsencrypt.c
@@ -679,7 +679,7 @@
unlock:
cifs_server_unlock(ses->server);
setup_ntlmv2_rsp_ret:
+ kfree(tiblob);
- kfree_sensitive(tiblob);
return rc;
}
@@ -753,14 +753,14 @@
server->secmech.ccmaesdecrypt = NULL;
}
+ kfree(server->secmech.sdesccmacaes);
- kfree_sensitive(server->secmech.sdesccmacaes);
server->secmech.sdesccmacaes = NULL;
+ kfree(server->secmech.sdeschmacsha256);
- kfree_sensitive(server->secmech.sdeschmacsha256);
server->secmech.sdeschmacsha256 = NULL;
+ kfree(server->secmech.sdeschmacmd5);
- kfree_sensitive(server->secmech.sdeschmacmd5);
server->secmech.sdeschmacmd5 = NULL;
+ kfree(server->secmech.sdescmd5);
- kfree_sensitive(server->secmech.sdescmd5);
server->secmech.sdescmd5 = NULL;
+ kfree(server->secmech.sdescsha512);
- kfree_sensitive(server->secmech.sdescsha512);
server->secmech.sdescsha512 = NULL;
}
reverted:
--- b/fs/cifs/connect.c
+++ a/fs/cifs/connect.c
@@ -288,7 +288,7 @@
}
server->sequence_number = 0;
server->session_estab = false;
+ kfree(server->session_key.response);
- kfree_sensitive(server->session_key.response);
server->session_key.response = NULL;
server->session_key.len = 0;
server->lstrp = jiffies;
@@ -1562,7 +1562,7 @@
cifs_crypto_secmech_release(server);
+ kfree(server->session_key.response);
- kfree_sensitive(server->session_key.response);
server->session_key.response = NULL;
server->session_key.len = 0;
kfree(server->hostname);
@@ -4097,7 +4097,7 @@
if (ses->auth_key.response) {
cifs_dbg(FYI, "Free previous auth_key.response = %p\n",
ses->auth_key.response);
+ kfree(ses->auth_key.response);
- kfree_sensitive(ses->auth_key.response);
ses->auth_key.response = NULL;
ses->auth_key.len = 0;
}
reverted:
--- b/fs/cifs/fs_context.c
+++ a/fs/cifs/fs_context.c
@@ -789,13 +789,6 @@
cifs_sb->ctx->field = NULL; \
} while (0)
-#define STEAL_STRING_SENSITIVE(cifs_sb, ctx, field) \
-do { \
- kfree_sensitive(ctx->field); \
- ctx->field = cifs_sb->ctx->field; \
- cifs_sb->ctx->field = NULL; \
-} while (0)
-
static int smb3_reconfigure(struct fs_context *fc)
{
struct smb3_fs_context *ctx = smb3_fc2context(fc);
@@ -816,7 +809,7 @@
STEAL_STRING(cifs_sb, ctx, UNC);
STEAL_STRING(cifs_sb, ctx, source);
STEAL_STRING(cifs_sb, ctx, username);
+ STEAL_STRING(cifs_sb, ctx, password);
- STEAL_STRING_SENSITIVE(cifs_sb, ctx, password);
STEAL_STRING(cifs_sb, ctx, domainname);
STEAL_STRING(cifs_sb, ctx, nodename);
STEAL_STRING(cifs_sb, ctx, iocharset);
@@ -1157,7 +1150,7 @@
}
break;
case Opt_pass:
+ kfree(ctx->password);
- kfree_sensitive(ctx->password);
ctx->password = NULL;
if (strlen(param->string) == 0)
break;
@@ -1465,7 +1458,6 @@
return 0;
cifs_parse_mount_err:
- kfree_sensitive(ctx->password);
return -EINVAL;
}
reverted:
--- b/fs/cifs/misc.c
+++ a/fs/cifs/misc.c
@@ -1118,7 +1118,7 @@
void
cifs_free_hash(struct crypto_shash **shash, struct sdesc **sdesc)
{
+ kfree(*sdesc);
- kfree_sensitive(*sdesc);
*sdesc = NULL;
if (*shash)
crypto_free_shash(*shash);
reverted:
--- b/fs/cifs/sess.c
+++ a/fs/cifs/sess.c
@@ -1211,12 +1211,6 @@
static void
sess_free_buffer(struct sess_data *sess_data)
{
- int i;
-
- /* zero the session data before freeing, as it might contain sensitive info (keys, etc) */
- for (i = 0; i < 3; i++)
- if (sess_data->iov[i].iov_base)
- memzero_explicit(sess_data->iov[i].iov_base, sess_data->iov[i].iov_len);
free_rsp_buf(sess_data->buf0_type, sess_data->iov[0].iov_base);
sess_data->buf0_type = CIFS_NO_BUFFER;
@@ -1378,7 +1372,7 @@
sess_data->result = rc;
sess_data->func = NULL;
sess_free_buffer(sess_data);
+ kfree(ses->auth_key.response);
- kfree_sensitive(ses->auth_key.response);
ses->auth_key.response = NULL;
}
@@ -1517,7 +1511,7 @@
sess_data->result = rc;
sess_data->func = NULL;
sess_free_buffer(sess_data);
+ kfree(ses->auth_key.response);
- kfree_sensitive(ses->auth_key.response);
ses->auth_key.response = NULL;
}
@@ -1652,7 +1646,7 @@
rc = decode_ntlmssp_challenge(bcc_ptr, blob_len, ses);
out_free_ntlmsspblob:
+ kfree(ntlmsspblob);
- kfree_sensitive(ntlmsspblob);
out:
sess_free_buffer(sess_data);
@@ -1662,9 +1656,9 @@
}
/* Else error. Cleanup */
+ kfree(ses->auth_key.response);
- kfree_sensitive(ses->auth_key.response);
ses->auth_key.response = NULL;
+ kfree(ses->ntlmssp);
- kfree_sensitive(ses->ntlmssp);
ses->ntlmssp = NULL;
sess_data->func = NULL;
@@ -1763,7 +1757,7 @@
}
out_free_ntlmsspblob:
+ kfree(ntlmsspblob);
- kfree_sensitive(ntlmsspblob);
out:
sess_free_buffer(sess_data);
@@ -1771,9 +1765,9 @@
rc = sess_establish_session(sess_data);
/* Cleanup */
+ kfree(ses->auth_key.response);
- kfree_sensitive(ses->auth_key.response);
ses->auth_key.response = NULL;
+ kfree(ses->ntlmssp);
- kfree_sensitive(ses->ntlmssp);
ses->ntlmssp = NULL;
sess_data->func = NULL;
@@ -1849,7 +1843,7 @@
rc = sess_data->result;
out:
+ kfree(sess_data);
- kfree_sensitive(sess_data);
return rc;
}
#endif /* CONFIG_CIFS_ALLOW_INSECURE_LEGACY */
reverted:
--- b/fs/cifs/smb2ops.c
+++ a/fs/cifs/smb2ops.c
@@ -4390,11 +4390,11 @@
if (!rc && enc)
memcpy(&tr_hdr->Signature, sign, SMB2_SIGNATURE_SIZE);
+ kfree(iv);
- kfree_sensitive(iv);
free_sg:
+ kfree(sg);
- kfree_sensitive(sg);
free_req:
+ kfree(req);
- kfree_sensitive(req);
return rc;
}
reverted:
--- b/fs/cifs/smb2pdu.c
+++ a/fs/cifs/smb2pdu.c
@@ -1333,13 +1333,6 @@
static void
SMB2_sess_free_buffer(struct SMB2_sess_data *sess_data)
{
- int i;
-
- /* zero the session data before freeing, as it might contain sensitive info (keys, etc) */
- for (i = 0; i < 2; i++)
- if (sess_data->iov[i].iov_base)
- memzero_explicit(sess_data->iov[i].iov_base, sess_data->iov[i].iov_len);
-
free_rsp_buf(sess_data->buf0_type, sess_data->iov[0].iov_base);
sess_data->buf0_type = CIFS_NO_BUFFER;
}
@@ -1472,8 +1465,6 @@
out_put_spnego_key:
key_invalidate(spnego_key);
key_put(spnego_key);
- if (rc)
- kfree_sensitive(ses->auth_key.response);
out:
sess_data->result = rc;
sess_data->func = NULL;
@@ -1570,7 +1561,7 @@
}
out:
+ kfree(ntlmssp_blob);
- memzero_explicit(ntlmssp_blob, blob_length);
SMB2_sess_free_buffer(sess_data);
if (!rc) {
sess_data->result = 0;
@@ -1578,7 +1569,7 @@
return;
}
out_err:
+ kfree(ses->ntlmssp);
- kfree_sensitive(ses->ntlmssp);
ses->ntlmssp = NULL;
sess_data->result = rc;
sess_data->func = NULL;
@@ -1654,9 +1645,9 @@
}
#endif
out:
+ kfree(ntlmssp_blob);
- memzero_explicit(ntlmssp_blob, blob_length);
SMB2_sess_free_buffer(sess_data);
+ kfree(ses->ntlmssp);
- kfree_sensitive(ses->ntlmssp);
ses->ntlmssp = NULL;
sess_data->result = rc;
sess_data->func = NULL;
@@ -1734,7 +1725,7 @@
cifs_server_dbg(VFS, "signing requested but authenticated as guest\n");
rc = sess_data->result;
out:
+ kfree(sess_data);
- kfree_sensitive(sess_data);
return rc;
}This is an automated interdiff check for backported commits. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Background
ecf0891583a31 HID: core: Harden s32ton() against conversion to 0 bitsaddresses CVE-2025-38556955a9289d3db8 tls: rx: fix return value for async cryptoaddresses CVE-2024-58239dbc0be4e25ae1 tls: fix handling of zero-length records on the rx_listaddresses CVE-2025-39682 and required four prerequisites:f6286d5109739 cifs: fix oops during encryptionaddresses CVE-2022-50341 and has one upstream bugfix:This PR also swaps out the branch local upstream-commit-check workflow for the validate-kernel-commits workflow provided by the main branch. This includes checks for upstream bugfixes, cve checking, interdiff and jira checking.
Commits
Build Log
Testing
selftest-5.14.0-284.30.1.el9_2.92ciq_lts.12.1.x86_64-1.log
selftest-5.14.0-bmastbergen_ciqlts9_2_many-vulns-2025-11-04-f94396fd2+-1.log