Export limit exceeded: 419502 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (3349 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-33235 | 2 Linux, Nvidia | 4 Linux, Linux Kernel, Nvidia Resiliency Extension and 1 more | 2026-02-02 | 7.8 High |
| NVIDIA Resiliency Extension for Linux contains a vulnerability in the checkpointing core, where an attacker may cause a race condition. A successful exploit of this vulnerability might lead to information disclosure, data tampering, denial of service, or escalation of privileges. | ||||
| CVE-2025-48753 | 1 Obsidiandynamics | 1 Anode | 2026-01-30 | 2.9 Low |
| In the anode crate 0.1.0 for Rust, data races can occur in unlock in SpinLock. | ||||
| CVE-2025-48751 | 1 Tickbh | 1 Process Lock | 2026-01-30 | 2.9 Low |
| The process_lock crate 0.1.0 for Rust allows data races in unlock. | ||||
| CVE-2025-47735 | 1 Nugine | 1 Wgp | 2026-01-30 | 2.9 Low |
| inner::drop in inner.rs in the wgp crate through 0.2.0 for Rust lacks drop_slow thread synchronization. | ||||
| CVE-2025-66803 | 1 Hotwired | 1 Turbo | 2026-01-30 | 4.8 Medium |
| Race condition in the turbo-frame element handler in Hotwired Turbo before 8.0.x causes logout operations to fail when delayed frame responses reapply session cookies after logout. This can be exploited by remote attackers via selective network delays (e.g. delaying requests based on sequence or timing) or by physically proximate attackers when the race condition occurs naturally on shared computers. | ||||
| CVE-2025-47907 | 1 Golang | 2 Database Sql, Go | 2026-01-29 | 7 High |
| Cancelling a query (e.g. by cancelling the context passed to one of the query methods) during a call to the Scan method of the returned Rows can result in unexpected results if other queries are being made in parallel. This can result in a race condition that may overwrite the expected results with those of another query, causing the call to Scan to return either unexpected results from the other query or an error. | ||||
| CVE-2022-39328 | 1 Grafana | 1 Grafana | 2026-01-28 | 9.8 Critical |
| Grafana is an open-source platform for monitoring and observability. Versions starting with 9.2.0 and less than 9.2.4 contain a race condition in the authentication middlewares logic which may allow an unauthenticated user to query an administration endpoint under heavy load. This issue is patched in 9.2.4. There are no known workarounds. | ||||
| CVE-2025-52517 | 1 Samsung | 16 Exynos, Exynos 1330, Exynos 1330 Firmware and 13 more | 2026-01-27 | 5.1 Medium |
| An issue was discovered in the Camera in Samsung Mobile Processor and Wearable Processor Exynos 1330, 1380, 1480, 2400, 1580, 2500. A race condition in the issimian device driver results in a double free, leading to a denial of service. | ||||
| CVE-2025-45731 | 1 2fauth | 1 2fauth | 2026-01-20 | 6.5 Medium |
| A group deletion race condition in 2FAuth v5.5.0 causes data inconsistencies and orphaned accounts when a group is deleted while other operations are pending. | ||||
| CVE-2023-53452 | 1 Linux | 1 Linux Kernel | 2026-01-16 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix potential race condition between napi_init and napi_enable A race condition can happen if netdev is registered, but NAPI isn't initialized yet, and meanwhile user space starts the netdev that will enable NAPI. Then, it hits BUG_ON(): kernel BUG at net/core/dev.c:6423! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91 Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022 RIP: 0010:napi_enable+0x3f/0x50 Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ... RSP: 0018:ffffada1414f3548 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000 RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58 R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001 FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8] rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] __dev_open+0xe0/0x180 __dev_change_flags+0x1da/0x250 dev_change_flags+0x26/0x70 do_setlink+0x37c/0x12c0 ? ep_poll_callback+0x246/0x290 ? __nla_validate_parse+0x61/0xd00 ? __wake_up_common_lock+0x8f/0xd0 To fix this, follow Jonas' suggestion to switch the order of these functions and move register netdev to be the last step of PCI probe. Also, correct the error handling of rtw89_core_register_hw(). | ||||
| CVE-2025-12383 | 1 Eclipse | 1 Jersey | 2026-01-16 | 7.4 High |
| In Eclipse Jersey versions 2.45, 3.0.16, 3.1.9 a race condition can cause ignoring of critical SSL configurations - such as mutual authentication, custom key/trust stores, and other security settings. This issue may result in SSLHandshakeException under normal circumstances, but under certain conditions, it could lead to unauthorized trust in insecure servers (see PoC) | ||||
| CVE-2025-68962 | 1 Huawei | 1 Harmonyos | 2026-01-15 | 5.1 Medium |
| Multi-thread race condition vulnerability in the camera framework module. Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2025-68961 | 1 Huawei | 1 Harmonyos | 2026-01-15 | 5.1 Medium |
| Multi-thread race condition vulnerability in the camera framework module. Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2025-68960 | 1 Huawei | 1 Harmonyos | 2026-01-15 | 8.4 High |
| Multi-thread race condition vulnerability in the video framework module. Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2025-68958 | 1 Huawei | 1 Harmonyos | 2026-01-15 | 8 High |
| Multi-thread race condition vulnerability in the card framework module. Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2025-68957 | 1 Huawei | 1 Harmonyos | 2026-01-15 | 8.4 High |
| Multi-thread race condition vulnerability in the card framework module. Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2025-68956 | 1 Huawei | 1 Harmonyos | 2026-01-15 | 8 High |
| Multi-thread race condition vulnerability in the card framework module. Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2025-68955 | 1 Huawei | 1 Harmonyos | 2026-01-15 | 8 High |
| Multi-thread race condition vulnerability in the card framework module. Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2025-68969 | 1 Huawei | 1 Harmonyos | 2026-01-15 | 6.8 Medium |
| Multi-thread race condition vulnerability in the thermal management module. Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2025-39905 | 1 Linux | 1 Linux Kernel | 2026-01-14 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver Currently phylink_resolve() protects itself against concurrent phylink_bringup_phy() or phylink_disconnect_phy() calls which modify pl->phydev by relying on pl->state_mutex. The problem is that in phylink_resolve(), pl->state_mutex is in a lock inversion state with pl->phydev->lock. So pl->phydev->lock needs to be acquired prior to pl->state_mutex. But that requires dereferencing pl->phydev in the first place, and without pl->state_mutex, that is racy. Hence the reason for the extra lock. Currently it is redundant, but it will serve a functional purpose once mutex_lock(&phy->lock) will be moved outside of the mutex_lock(&pl->state_mutex) section. Another alternative considered would have been to let phylink_resolve() acquire the rtnl_mutex, which is also held when phylink_bringup_phy() and phylink_disconnect_phy() are called. But since phylink_disconnect_phy() runs under rtnl_lock(), it would deadlock with phylink_resolve() when calling flush_work(&pl->resolve). Additionally, it would have been undesirable because it would have unnecessarily blocked many other call paths as well in the entire kernel, so the smaller-scoped lock was preferred. | ||||