Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
during shadow population also ignore the external gfp_mask. To preserve the intended semantics of GFP_NOFS and GFP_NOIO, wrap the apply_to_page_range() calls into the appropriate memalloc scope. xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock. There was a report here https://lkml.kernel.org/r/686ea951.050a0220.385921.0016.GAE@google.com This patch: - Extends kasan_populate_vmalloc() and helpers to take gfp_mask; - Passes gfp_mask down to alloc_pages_bulk() and __get_free_page(); - Enforces GFP_NOFS/NOIO semantics with memalloc_*_save()/restore() around apply_to_page_range(); - Updates vmalloc.c and percpu allocator call sites accordingly. References: - https://git.kernel.
pply_to_page_range(); - Updates vmalloc.c and percpu allocator call sites accordingly. References: - https://git.kernel.org/stable/c/33b95d90427cb4babf32059e323a6d0c027610fe - https://git.kernel.org/stable/c/79357cd06d41d0f5a11b17d7c86176e395d10ef2
CVE ID: CVE-2025-39911 State: PUBLISHED Published: 2025-10-01T07:44:34.561Z Last Updated: 2025-11-03T17:44:36.010Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration later than the first, the error path wants to free the IRQs requested so far. However, it uses the wrong dev_id argument for free_irq(), so it does not free the IRQs correctly and instead triggers the warning: Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in
ree already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: <TASK> free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_se
rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x3a2/0x3d0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] </TASK> ---[ end trace 0000000000000000 ]--- Use the same dev_id for free_irq() as for request_irq(). I tested this with inserting code to fail intentionally. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/13ab9adef3cd386511c930a9660ae06595007f89 - https://git.kernel.org/stable/c/6e4016c0dca53afc71e3b99e24252b63417395df - https://git.kernel.org/stable/c/b9721a0
f89 - https://git.kernel.org/stable/c/6e4016c0dca53afc71e3b99e24252b63417395df - https://git.kernel.org/stable/c/b9721a023df38cf44a88f2739b4cf51efd051f85 - https://git.kernel.org/stable/c/b905b2acb3a0bbb08ad9be9984d8cdabdf827315 - https://git.kernel.org/stable/c/23431998a37764c464737b855c71a81d50992e98 - https://git.kernel.org/stable/c/a30afd6617c30aaa338d1dbcb1e34e7a1890085c - https://git.kernel.org/stable/c/c62580674ce5feb1be4f90b5873ff3ce50e0a1db - https://git.kernel.org/stable/c/915470e1b44e71d1dd07ee067276f003c3521ee3
CVE ID: CVE-2025-39912 State: PUBLISHED Published: 2025-10-01T07:44:35.513Z Last Updated: 2025-10-01T07:44:35.513Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nfs/localio: restore creds before releasing pageio data Otherwise if the nfsd filecache code releases the nfsd_file immediately, it can trigger the BUG_ON(cred == current->cred) in __put_cred() when it puts the nfsd_file->nf_file->f-cred. References: - https://git.kernel.org/stable/c/57c1bb02b4fc8eec6eb01736e7fad26dffacf18c - https://git.kernel.org/stable/c/c250be1d75bf80dc5ab46f0b434b746c1868a1ea - https://git.kernel.org/stable/c/992203a1fba51b025c60ec0c8b0d9223343dea
able/c/c250be1d75bf80dc5ab46f0b434b746c1868a1ea - https://git.kernel.org/stable/c/992203a1fba51b025c60ec0c8b0d9223343dea95
CVE ID: CVE-2025-39913 State: PUBLISHED Published: 2025-10-01T07:44:36.244Z Last Updated: 2025-11-03T17:44:36.959Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork. syzbot reported the splat below. [0] The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytes At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes().
, the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes(). Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN. If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc(). Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork. The "*copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "*copied" to 0. [0]: WARNING: net/ipv4/af_inet.c:156 at inet_s
Nothing has been corked so far, so this patch simply sets "*copied" to 0. [0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ff
<0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> __sk_destruct+0x86/0x660 net/core/sock.c:2339 rc
5604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ> Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/08f58d10f5abf1
2 </IRQ> Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/08f58d10f5abf11d297cc910754922498c921f91 - https://git.kernel.org/stable/c/05366527f44cf4b884f3d9462ae8009be9665856 - https://git.kernel.org/stable/c/7429b8b9bfbc276fd304fbaebc405f46b421fedf - https://git.kernel.org/stable/c/9c2a6456bdf9794474460d885c359b6c4522d6e3 - https://git.kernel.org/stable/c/66bcb04a441fbf15d66834b7e3eefb313dd750c8 - https://git.kernel.org/stable/c/539920180c55f5e13a2488a2339f94e6b8cb69e0 - https://git.kernel.org/stable/c/de89e58368f8f07df005ecc1c86ad94898a999f2 - https://git.kernel.org/stable/c/a3967baad4d533dc254c31e0d221e51c8d223d58
CVE ID: CVE-2025-39914 State: PUBLISHED Published: 2025-10-01T07:44:37.018Z Last Updated: 2025-11-03T17:44:37.896Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Silence warning when chunk allocation fails in trace_pid_write Syzkaller trigger a fault injection warning: WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 b
e RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 D
000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x2
677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning
ssign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning. The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7583a73c53f1d1ae7a39b130eb7190a11f0a902f - https://git.kernel.org/stable/c/1262bda871dace8c6efae25f3b6a2d34f6f06d54 - https://git.kernel.org/stable/
90a11f0a902f - https://git.kernel.org/stable/c/1262bda871dace8c6efae25f3b6a2d34f6f06d54 - https://git.kernel.org/stable/c/88525accf16947ab459f8e91c27c8c53e1d612d7 - https://git.kernel.org/stable/c/793338906ff57d8c683f44fe48ca99d49c8782a7 - https://git.kernel.org/stable/c/cd4453c5e983cf1fd5757e9acb915adb1e4602b6
CVE ID: CVE-2025-39915 State: PUBLISHED Published: 2025-10-01T07:44:37.884Z Last Updated: 2025-10-01T07:44:37.884Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: phy: transfer phy_config_inband() locking responsibility to phylink Problem description =================== Lockdep reports a possible circular locking dependency (AB/BA) between &pl->state_mutex and &phy->lock, as follows. phylink_resolve() // acquires &pl->state_mutex -> phylink_major_config() -> phy_config_inband() // acquires &pl->phydev->lock whereas all the other call sites where &pl->state_mutex and &pl->phydev->lock have the locking scheme reversed. Everyw
k whereas all the other call sites where &pl->state_mutex and &pl->phydev->lock have the locking scheme reversed. Everywhere else, &pl->phydev->lock is acquired at the top level, and &pl->state_mutex at the lower level. A clear example is phylink_bringup_phy(). The outlier is the newly introduced phy_config_inband() and the existing lock order is the correct one. To understand why it cannot be the other way around, it is sufficient to consider phylink_phy_change(), phylink's callback from the PHY device's phy->phy_link_change() virtual method, invoked by the PHY state machine. phy_link_up() and phy_link_down(), the (indirect) callers of phylink_phy_change(), are called with &phydev->lock acq
ne. phy_link_up() and phy_link_down(), the (indirect) callers of phylink_phy_change(), are called with &phydev->lock acquired. Then phylink_phy_change() acquires its own &pl->state_mutex, to serialize changes made to its pl->phy_state and pl->link_config. So all other instances of &pl->state_mutex and &phydev->lock must be consistent with this order. Problem impact ============== I think the kernel runs a serious deadlock risk if an existing phylink_resolve() thread, which results in a phy_config_inband() call, is concurrent with a phy_link_up() or phy_link_down() call, which will deadlock on &pl->state_mutex in phylink_phy_change(). Practically speaking, the impact may be limited by the slo
ch will deadlock on &pl->state_mutex in phylink_phy_change(). Practically speaking, the impact may be limited by the slow speed of the medium auto-negotiation protocol, which makes it unlikely for the current state to still be unresolved when a new one is detected, but I think the problem is there. Nonetheless, the problem was discovered using lockdep. Proposed solution ================= Practically speaking, the phy_config_inband() requirement of having phydev->lock acquired must transfer to the caller (phylink is the only caller). There, it must bubble up until immediately before &pl->state_mutex is acquired, for the cases where that takes place. Solution details, considerations, notes ===
y before &pl->state_mutex is acquired, for the cases where that takes place. Solution details, considerations, notes ======================================= This is the phy_config_inband() call graph: sfp_upstream_ops :: connect_phy() | v phylink_sfp_connect_phy() | v phylink_sfp_config_phy() | | sfp_upstream_ops :: module_insert() | | | v | phylink_sfp_module_insert() | | | | sfp_upstream_ops :: module_start() | | | | | v | | phylink_sfp_module_start() | | | | v v | phylink_sfp_config_optical() phylink_start() | | | phylink_resume() v v | | phylink_sfp_set_config() | | | v v v phylink_mac_initial_config() | phylink_resolve() | | phylink_ethtool_ksettings_set() v v v phylink_major_config() |
v v phylink_mac_initial_config() | phylink_resolve() | | phylink_ethtool_ksettings_set() v v v phylink_major_config() | v phy_config_inband() phylink_major_config() caller #1, phylink_mac_initial_config(), does not acquire &pl->state_mutex nor do its callers. It must acquire &pl->phydev->lock prior to calling phylink_major_config(). phylink_major_config() caller #2, phylink_resolve() acquires &pl->state_mutex, thus also needs to acquire &pl->phydev->lock. phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is completely uninteresting, because it only call ---truncated--- References: - https://git.kernel.org/stable/c/052ac41c379c8b87629808be612a482b2d0ae283 - https://git.kerne
-truncated--- References: - https://git.kernel.org/stable/c/052ac41c379c8b87629808be612a482b2d0ae283 - https://git.kernel.org/stable/c/e2a10daba84968f6b5777d150985fd7d6abc9c84
CVE ID: CVE-2025-39916 State: PUBLISHED Published: 2025-10-01T07:44:38.690Z Last Updated: 2025-11-03T17:44:38.840Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters() When creating a new scheme of DAMON_RECLAIM, the calculation of 'min_age_region' uses 'aggr_interval' as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/64dc351e58271c1e9005e42f5216b4f3d7a39b66 - https://git.kernel.org/stable/c/9fe
rences: - https://git.kernel.org/stable/c/64dc351e58271c1e9005e42f5216b4f3d7a39b66 - https://git.kernel.org/stable/c/9fe0415156fbde773b31f920201cb70b1f0e40fe - https://git.kernel.org/stable/c/5d6eeb3c683c777ed4538eb3a650bb7da17a7cff - https://git.kernel.org/stable/c/40cb9b38b645126fdd1d6aa3d6811a8ad50ddfa1 - https://git.kernel.org/stable/c/e6b543ca9806d7bced863f43020e016ee996c057
CVE ID: CVE-2025-39917 State: PUBLISHED Published: 2025-10-01T07:44:39.423Z Last Updated: 2025-10-01T07:44:39.423Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds dynptr write in bpf_crypto_crypt Stanislav reported that in bpf_crypto_crypt() the destination dynptr's size is not validated to be at least as large as the source dynptr's size before calling into the crypto backend with 'len = src_len'. This can result in an OOB write when the destination is smaller than the source. Concretely, in mentioned function, psrc and pdst are both linear buffers fetched from each dynptr: psrc = __bpf_dynptr_data(src, s
, in mentioned function, psrc and pdst are both linear buffers fetched from each dynptr: psrc = __bpf_dynptr_data(src, src_len); [...] pdst = __bpf_dynptr_data_rw(dst, dst_len); [...] err = decrypt ? ctx->type->decrypt(ctx->tfm, psrc, pdst, src_len, piv) : ctx->type->encrypt(ctx->tfm, psrc, pdst, src_len, piv); The crypto backend expects pdst to be large enough with a src_len length that can be written. Add an additional src_len > dst_len check and bail out if it's the case. Note that these kfuncs are accessible under root privileges only. References: - https://git.kernel.org/stable/c/0126358df12d6f476f79251d9c398ac5c1b3062d - https://git.kernel.org/stable/c/c4be24ef0510c146dca4671effb127e97
rg/stable/c/0126358df12d6f476f79251d9c398ac5c1b3062d - https://git.kernel.org/stable/c/c4be24ef0510c146dca4671effb127e97631534b - https://git.kernel.org/stable/c/f9bb6ffa7f5ad0f8ee0f53fc4a10655872ee4a14
CVE ID: CVE-2025-39918 State: PUBLISHED Published: 2025-10-01T07:55:13.851Z Last Updated: 2025-10-01T07:55:13.851Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix linked list corruption Never leave scheduled wcid entries on the temporary on-stack list References: - https://git.kernel.org/stable/c/e4d5a5fc61fdc65220a1ce078d24c1d20bbb0835 - https://git.kernel.org/stable/c/c91a59b04f928cb4a1436b0e0a27650883d0388a - https://git.kernel.org/stable/c/49fba87205bec14a0f6bd997635bf3968408161e
CVE ID: CVE-2025-39919 State: PUBLISHED Published: 2025-10-01T07:55:14.804Z Last Updated: 2025-10-01T07:55:14.804Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: add missing check for rx wcid entries Non-station wcid entries must not be passed to the rx functions. In case of the global wcid entry, it could even lead to corruption in the wcid array due to pointer being casted to struct mt7996_sta_link using container_of. References: - https://git.kernel.org/stable/c/69dcc19048fcdc3fb166fd25b805470ee8fc0eb1 - https://git.kernel.org/stable/c/4a522b01e368eec58d182ecc47d24f49a39e440d
CVE ID: CVE-2025-39920 State: PUBLISHED Published: 2025-10-01T07:55:15.731Z Last Updated: 2025-11-03T17:44:40.739Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pcmcia: Add error handling for add_interval() in do_validate_mem() In the do_validate_mem(), the call to add_interval() does not handle errors. If kmalloc() fails in add_interval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when sub_interval() is called next. This patch adds an error handling for the add_interval(). If add_interval() returns an error, the function will return early with the error code. Addit
ng for the add_interval(). If add_interval() returns an error, the function will return early with the error code. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/5b60ed401b47897352c520bc724c85aa908dedcc - https://git.kernel.org/stable/c/ae184024ef31423e5beb44cf4f52999bbcf2fe5b - https://git.kernel.org/stable/c/85be7ef8c8e792a414940a38d94565dd48d2f236 - https://git.kernel.org/stable/c/06b26e3099207c94b3d1be8565aedc6edc4f0a60 - https://git.kernel.org/stable/c/8699358b6ac99b8ccc97ed9e6e3669ef8958ef7b - https://git.kernel.org/stable/c/289b58f8ff3198d091074a751d6b8f6827726f3e - https://git.kernel.org/stable/c/369bf6e241506583f4ee7593c53b92e5a9f271
able/c/289b58f8ff3198d091074a751d6b8f6827726f3e - https://git.kernel.org/stable/c/369bf6e241506583f4ee7593c53b92e5a9f271b4 - https://git.kernel.org/stable/c/4a81f78caa53e0633cf311ca1526377d9bff7479
CVE ID: CVE-2025-39921 State: PUBLISHED Published: 2025-10-01T07:55:16.540Z Last Updated: 2025-10-01T07:55:16.540Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: microchip-core-qspi: stop checking viability of op->max_freq in supports_op callback In commit 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem operation frequency switches") the logic for checking the viability of op->max_freq in mchp_coreqspi_setup_clock() was copied into mchp_coreqspi_supports_op(). Unfortunately, op->max_freq is not valid when this function is called during probe but is instead zero. Accordingly, baud_rate_val is calculated to be
not valid when this function is called during probe but is instead zero. Accordingly, baud_rate_val is calculated to be INT_MAX due to division by zero, causing probe of the attached memory device to fail. Seemingly spi-microchip-core-qspi was the only driver that had such a modification made to its supports_op callback when the per_op_freq capability was added, so just remove it to restore prior functionality. References: - https://git.kernel.org/stable/c/ac8a13f35d5b8996582b3f97b924838a5c570c18 - https://git.kernel.org/stable/c/89e7353f522f5cf70cb48c01ce2dcdcb275b8022
CVE ID: CVE-2025-39922 State: PUBLISHED Published: 2025-10-01T07:55:17.475Z Last Updated: 2025-10-01T07:55:17.475Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ixgbe: fix incorrect map used in eee linkmode incorrectly used ixgbe_lp_map in loops intended to populate the supported and advertised EEE linkmode bitmaps based on ixgbe_ls_map. This results in incorrect bit setting and potential out-of-bounds access, since ixgbe_lp_map and ixgbe_ls_map have different sizes and purposes. ixgbe_lp_map[i] -> ixgbe_ls_map[i] Use ixgbe_ls_map for supported and advertised linkmodes, and keep ixgbe_lp_map usage only for link partner (lp_adv