CVE & Exploit Intelligence Database

CVE-2025-55226 6.7 MEDIUM 1 PoC Analysis EPSS 0.00

Concurrent execution using shared resource with improper synchronization ('race condition') in Graphics Kernel allows an authorized attacker to execute code locally.

CWE-362 Sep 09, 2025

CVE-2025-55224 7.8 HIGH EPSS 0.00

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Win32K - GRFX allows an authorized attacker to execute code locally.

CWE-362 Sep 09, 2025

CVE-2025-55223 7.0 HIGH EPSS 0.00

Concurrent execution using shared resource with improper synchronization ('race condition') in Graphics Kernel allows an authorized attacker to elevate privileges locally.

CWE-362 Sep 09, 2025

CVE-2025-54919 7.5 HIGH EPSS 0.00

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Win32K - GRFX allows an authorized attacker to execute code locally.

CWE-362 Sep 09, 2025

CVE-2025-54913 7.8 HIGH EPSS 0.00

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows UI XAML Maps MapControlSettings allows an authorized attacker to elevate privileges locally.

CWE-362 Sep 09, 2025

CVE-2025-54115 7.0 HIGH EPSS 0.00

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Hyper-V allows an authorized attacker to elevate privileges locally.

CWE-362 Sep 09, 2025

CVE-2025-54114 7.0 HIGH EPSS 0.00

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Connected Devices Platform Service allows an authorized attacker to elevate privileges locally.

CWE-362 Sep 09, 2025

CVE-2025-54108 7.0 HIGH EPSS 0.00

Concurrent execution using shared resource with improper synchronization ('race condition') in Capability Access Management Service (camsvc) allows an authorized attacker to elevate privileges locally.

CWE-362 Sep 09, 2025

CVE-2025-54105 7.0 HIGH EPSS 0.00

Concurrent execution using shared resource with improper synchronization ('race condition') in Microsoft Brokering File System allows an authorized attacker to elevate privileges locally.

CWE-362 Sep 09, 2025

CVE-2025-54092 7.8 HIGH EPSS 0.00

Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Hyper-V allows an authorized attacker to elevate privileges locally.

CWE-362 Sep 09, 2025

CVE-2025-53807 7.0 HIGH EPSS 0.00

Concurrent execution using shared resource with improper synchronization ('race condition') in Microsoft Graphics Component allows an authorized attacker to elevate privileges locally.

CWE-362 Sep 09, 2025

CVE-2025-47997 6.5 MEDIUM EPSS 0.00

Concurrent execution using shared resource with improper synchronization ('race condition') in SQL Server allows an authorized attacker to disclose information over a network.

CWE-362 Sep 09, 2025

CVE-2025-39726 4.7 MEDIUM EPSS 0.00

In the Linux kernel, the following vulnerability has been resolved: s390/ism: fix concurrency management in ism_cmd() The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that. This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well. A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it. On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.

CWE-362 Sep 05, 2025

CVE-2025-39697 4.7 MEDIUM EPSS 0.00

In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a race when updating an existing write After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head. So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request().

CWE-362 Sep 05, 2025

CVE-2025-39673 4.7 MEDIUM EPSS 0.00

In the Linux kernel, the following vulnerability has been resolved: ppp: fix race conditions in ppp_fill_forward_path ppp_fill_forward_path() has two race conditions: 1. The ppp->channels list can change between list_empty() and list_first_entry(), as ppp_lock() is not held. If the only channel is deleted in ppp_disconnect_channel(), list_first_entry() may access an empty head or a freed entry, and trigger a panic. 2. pch->chan can be NULL. When ppp_unregister_channel() is called, pch->chan is set to NULL before pch is removed from ppp->channels. Fix these by using a lockless RCU approach: - Use list_first_or_null_rcu() to safely test and access the first list entry. - Convert list modifications on ppp->channels to their RCU variants and add synchronize_net() after removal. - Check for a NULL pch->chan before dereferencing it.

CWE-362 Sep 05, 2025

CVE-2025-58313 5.1 MEDIUM EPSS 0.00

Race condition vulnerability in the device standby module. Impact: Successful exploitation of this vulnerability may cause feature exceptions of the device standby module.

CWE-362 Sep 05, 2025

CVE-2025-58296 7.5 HIGH EPSS 0.00

Race condition vulnerability in the audio module. Impact: Successful exploitation of this vulnerability may affect function stability.

CWE-362 Sep 05, 2025

CVE-2025-48548 7.3 HIGH EPSS 0.00

In multiple functions of AppOpsControllerImpl.java, there is a possible way to record audio without displaying the privacy indicator due to a race condition. This could lead to local escalation of privilege with User execution privileges needed. User interaction is needed for exploitation.

CWE-362 Sep 04, 2025

CVE-2025-48533 7.0 HIGH EPSS 0.00

In multiple locations, there is a possible way to use apps linked from a context menu of a lockscreen app due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

CWE-362 Sep 04, 2025

CVE-2025-38717 4.7 MEDIUM EPSS 0.00

In the Linux kernel, the following vulnerability has been resolved: net: kcm: Fix race condition in kcm_unattach() syzbot found a race condition when kcm_unattach(psock) and kcm_release(kcm) are executed at the same time. kcm_unattach() is missing a check of the flag kcm->tx_stopped before calling queue_work(). If the kcm has a reserved psock, kcm_unattach() might get executed between cancel_work_sync() and unreserve_psock() in kcm_release(), requeuing kcm->tx_work right before kcm gets freed in kcm_done(). Remove kcm->tx_stopped and replace it by the less error-prone disable_work_sync().

CWE-362 Sep 04, 2025