[FIPS-9.2] Multiple VULNS 22/10/25 #645
Merged
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-67702 cve CVE-2025-37797 commit-author Cong Wang <[email protected]> commit 3df275e This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class handling. The issue occurs due to a time-of-check/time-of-use condition in hfsc_change_class() when working with certain child qdiscs like netem or codel. The vulnerability works as follows: 1. hfsc_change_class() checks if a class has packets (q.qlen != 0) 2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g., codel, netem) might drop packets and empty the queue 3. The code continues assuming the queue is still non-empty, adding the class to vttree 4. This breaks HFSC scheduler assumptions that only non-empty classes are in vttree 5. Later, when the class is destroyed, this can lead to a Use-After-Free The fix adds a second queue length check after qdisc_peek_len() to verify the queue wasn't emptied. Fixes: 21f4d5c ("net_sched/hfsc: fix curve activation in hfsc_change_class()") Reported-by: Gerrard Tai <[email protected]> Reviewed-by: Konstantin Khlebnikov <[email protected]> Signed-off-by: Cong Wang <[email protected]> Reviewed-by: Jamal Hadi Salim <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 3df275e) Signed-off-by: Shreeya Patel <[email protected]>
…r length jira VULN-67719 cve CVE-2025-37810 commit-author Frode Isaksen <[email protected]> commit 63ccd26 The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34 Signed-off-by: Frode Isaksen <[email protected]> Fixes: 72246da ("usb: Introduce DesignWare USB3 DRD Driver") Cc: stable <[email protected]> Acked-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 63ccd26) Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-67738 cve CVE-2025-37823 commit-author Cong Wang <[email protected]> commit 6ccbda4 Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer. Fixes: 1da177e ("Linux-2.6.12-rc2") Reported-by: Gerrard Tai <[email protected]> Signed-off-by: Cong Wang <[email protected]> Reviewed-by: Jamal Hadi Salim <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 6ccbda4) Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-73375 cve CVE-2025-37914 commit-author Victor Nogueira <[email protected]> commit 1a6d0c0 As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of ets, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption. In addition to checking for qlen being zero, this patch checks whether the class was already added to the active_list (cl_is_active) before doing the addition to cater for the reentrant case. [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/ Fixes: 37d9cf1 ("sched: Fix detection of empty queues in child qdiscs") Acked-by: Jamal Hadi Salim <[email protected]> Signed-off-by: Victor Nogueira <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 1a6d0c0) Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-70981 cve CVE-2025-38079 commit-author Ivan Pravdin <[email protected]> commit b2df03e If accept(2) is called on socket type algif_hash with MSG_MORE flag set and crypto_ahash_import fails, sk2 is freed. However, it is also freed in af_alg_release, leading to slab-use-after-free error. Fixes: fe869cd ("crypto: algif_hash - User-space interface for hash operations") Cc: <[email protected]> Signed-off-by: Ivan Pravdin <[email protected]> Signed-off-by: Herbert Xu <[email protected]> (cherry picked from commit b2df03e) Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-71596 cve CVE-2025-38086 commit-author Qasim Ijaz <[email protected]> commit 9ad0452 In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read(): if (err == size) { memcpy(data, buf, size); } If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read(): return (buff[0] | buff[1] << 8); The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff". To fix this we should check the return value of control_read() and return early on error. Reported-by: syzbot <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=3361c2d6f78a3e0892f9 Tested-by: syzbot <[email protected]> Fixes: 4a476bd ("usbnet: New driver for QinHeng CH9200 devices") Cc: [email protected] Signed-off-by: Qasim Ijaz <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 9ad0452) Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-71890 cve CVE-2025-38159 commit-author Alexey Kodanev <[email protected]> commit 4c2c372 Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads 5 bytes: void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4)); Detected using the static analysis tool - Svace. Fixes: 4136214 ("rtw88: add BT co-existence support") Signed-off-by: Alexey Kodanev <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] (cherry picked from commit 4c2c372) Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-71951 cve CVE-2025-38177 commit-author Cong Wang <[email protected]> commit 51eb3b6 hfsc_qlen_notify() is not idempotent either and not friendly to its callers, like fq_codel_dequeue(). Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life: 1. update_vf() decreases cl->cl_nactive, so we can check whether it is non-zero before calling it. 2. eltree_remove() always removes RB node cl->el_node, but we can use RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe. Reported-by: Gerrard Tai <[email protected]> Signed-off-by: Cong Wang <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Jamal Hadi Salim <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> (cherry picked from commit 51eb3b6) Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-72066 cve CVE-2025-38200 commit-author Kyungwook Boo <[email protected]> commit 015bac5 When the device sends a specific input, an integer underflow can occur, leading to MMIO write access to an invalid page. Prevent the integer underflow by changing the type of related variables. Signed-off-by: Kyungwook Boo <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/T/ Reviewed-by: Przemek Kitszel <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Aleksandr Loktionov <[email protected]> Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> (cherry picked from commit 015bac5) Signed-off-by: Shreeya Patel <[email protected]>
jira VULN-80686 cve CVE-2025-38461 commit-author Michal Luczaj <[email protected]> commit 687aa0c Transport assignment may race with module unload. Protect new_transport from becoming a stale pointer. This also takes care of an insecure call in vsock_use_local_transport(); add a lockdep assert. BUG: unable to handle page fault for address: fffffbfff8056000 Oops: Oops: 0000 [#1] SMP KASAN RIP: 0010:vsock_assign_transport+0x366/0x600 Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: c0cfa2d ("vsock: add multi-transports support") Reviewed-by: Stefano Garzarella <[email protected]> Signed-off-by: Michal Luczaj <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> (cherry picked from commit 687aa0c) Signed-off-by: Shreeya Patel <[email protected]>
🔍 Upstream Linux Kernel Commit Check
This is an automated message from the kernel commit checker workflow. |
jira VULN-80686 cve-bf CVE-2025-38461 commit-author Stefano Garzarella <[email protected]> commit f7c877e Syzbot reported a potential lock inversion deadlock between vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called. The issue was introduced by commit 687aa0c ("vsock: Fix transport_* TOCTOU") which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call, that can call vsock_linger(). vsock_assign_transport() can be called with sk_lock held. vsock_linger() calls sk_wait_event() that temporarily releases and re-acquires sk_lock. During this window, if another thread hold vsock_register_mutex while trying to acquire sk_lock, a circular dependency is created. Fix this by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(). This is safe because we don't need to hold vsock_register_mutex while releasing the old transport, and we ensure the new transport won't disappear by obtaining a module reference first via try_module_get(). Reported-by: [email protected] Tested-by: [email protected] Fixes: 687aa0c ("vsock: Fix transport_* TOCTOU") Cc: [email protected] Cc: [email protected] Signed-off-by: Stefano Garzarella <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> (cherry picked from commit f7c877e) Signed-off-by: Shreeya Patel <[email protected]>
bmastbergen
approved these changes
Oct 27, 2025
There was a problem hiding this comment.
github's representation of the change on the 'vsock: fix lock inversion....' commit is a little different than the way the upstream change is shown which was confusing, but I think you end up with the correct code. interdiff caught this as well (see below):
FF] PR commit 8b89afe7ed553 (vsock: fix lock inversion in vsock_assign_transport()) → upstream f7c877e75352
Differences found:
interdiff impossible; taking evasive action
reverted:
--- b/net/vmw_vsock/af_vsock.c
+++ a/net/vmw_vsock/af_vsock.c
@@ -479,9 +479,20 @@
goto err;
}
+ if (vsk->transport) {
+ if (vsk->transport == new_transport) {
+ ret = 0;
+ goto err;
+ }
+
+ /* transport->release() must be called with sock lock acquired.
+ * This path can only be taken during vsock_connect(), where we
+ * have already held the sock lock. In the other cases, this
+ * function is called on a new socket which is not assigned to
+ * any transport.
+ */
+ vsk->transport->release(vsk);
+ vsock_deassign_transport(vsk);
- if (vsk->transport && vsk->transport == new_transport) {
- ret = 0;
- goto err;
}
/* We increase the module refcnt to prevent the transport unloading
@@ -498,17 +509,6 @@
*/
mutex_unlock(&vsock_register_mutex);
- if (vsk->transport) {
- /* transport->release() must be called with sock lock acquired.
- * This path can only be taken during vsock_connect(), where we
- * have already held the sock lock. In the other cases, this
- * function is called on a new socket which is not assigned to
- * any transport.
- */
- vsk->transport->release(vsk);
- vsock_deassign_transport(vsk);
- }
-
if (sk->sk_type == SOCK_SEQPACKET) {
if (!new_transport->seqpacket_allow ||
!new_transport->seqpacket_allow(remote_cid)) {
unchanged:
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -487,12 +487,26 @@ int vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk)
goto err;
}
- if (vsk->transport) {
- if (vsk->transport == new_transport) {
- ret = 0;
- goto err;
- }
+ if (vsk->transport && vsk->transport == new_transport) {
+ ret = 0;
+ goto err;
+ }
+ /* We increase the module refcnt to prevent the transport unloading
+ * while there are open sockets assigned to it.
+ */
+ if (!new_transport || !try_module_get(new_transport->module)) {
+ ret = -ENODEV;
+ goto err;
+ }
+
+ /* It's safe to release the mutex after a successful try_module_get().
+ * Whichever transport `new_transport` points at, it won't go away until
+ * the last module_put() below or in vsock_deassign_transport().
+ */
+ mutex_unlock(&vsock_register_mutex);
+
+ if (vsk->transport) {
/* transport->release() must be called with sock lock acquired.
* This path can only be taken during vsock_connect(), where we
* have already held the sock lock. In the other cases, this
@@ -512,20 +526,6 @@ int vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk)
vsk->peer_shutdown = 0;
}
- /* We increase the module refcnt to prevent the transport unloading
- * while there are open sockets assigned to it.
- */
- if (!new_transport || !try_module_get(new_transport->module)) {
- ret = -ENODEV;
- goto err;
- }
-
- /* It's safe to release the mutex after a successful try_module_get().
- * Whichever transport `new_transport` points at, it won't go away until
- * the last module_put() below or in vsock_deassign_transport().
- */
- mutex_unlock(&vsock_register_mutex);
-
if (sk->sk_type == SOCK_SEQPACKET) {
if (!new_transport->seqpacket_allow ||
!new_transport->seqpacket_allow(remote_cid)) {
Yeah this was wild. It the big fun is we're also mistsing this which is expected and not associated with this a24009b but its not in the VULNs list so not a huge deal since this branch will get merged into the standard LTS eventually. |
shreeya-patel98
merged commit ab3971c
into
fips-9-compliant/5.14.0-284.30.1
3 checks passed
shreeya-patel98
deleted the
{shreeya}_fips-9-compliant/5.14.0-284.30.1
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
Commits
Kernel Build Log
kernel-build.log
Testing
kselftest-after.log
kselftest-before.log