CVE Intelligence
Home / CVEs

CVE Database

Published vulnerabilities with severity, known exploitation and official sources.

Severity
Clear

973 result(s)

Export this search: RSS · CSV · STIX
CVE-2026-24296 High · 7.0 CWE-362 Mar 10, 2026
Windows Device Association Service Elevation of Privilege Vulnerability
Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Device Association Service allows an authorized attacker to elevate privileges locally.
CVE-2026-24295 High · 7.0 CWE-362 Mar 10, 2026
Windows Device Association Service Elevation of Privilege Vulnerability
Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Device Association Service allows an authorized attacker to elevate privileges locally.
CVE-2026-23671 High · 7.0 CWE-362 Mar 10, 2026
Windows Bluetooth RFCOM Protocol Driver Elevation of Privilege Vulnerability
Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Bluetooth RFCOM Protocol Driver allows an authorized attacker to elevate privileges locally.
CVE-2026-23668 High · 7.0 CWE-362 Mar 10, 2026
Windows Graphics Component Elevation of Privilege Vulnerability
Concurrent execution using shared resource with improper synchronization ('race condition') in Microsoft Graphics Component allows an authorized attacker to elevate privileges locally.
CVE-2026-23240 Critical · 9.8 CWE-362 Mar 10, 2026
tls: Fix race condition in tls_sw_cancel_work_tx()
In the Linux kernel, the following vulnerability has been resolved: tls: Fix race condition in tls_sw_cancel_work_tx() This issue was discovered during a code audit. After cancel_delayed_work_sync() is called from tls_sk_proto_close(), tx_work_handler() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the tx_work_handler() worker may dereference a freed TLS object. The following is a simple race scenario: cpu0 cpu1 tls_sk_proto_close() tls_sw_cancel_work_tx() tls_write_space() tls_sw_write_space() if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask)) set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask); cancel_delayed_work_sync(&ctx->tx_work.work); schedule_delayed_work(&tx_ctx->tx_work.work, 0); To prevent this race condition, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync().
CVE-2026-23239 High · 7.8 CWE-362 Mar 10, 2026
espintcp: Fix race condition in espintcp_close()
In the Linux kernel, the following vulnerability has been resolved: espintcp: Fix race condition in espintcp_close() This issue was discovered during a code audit. After cancel_work_sync() is called from espintcp_close(), espintcp_tx_work() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the espintcp_tx_work() worker may dereference a freed espintcp ctx or sk. The following is a simple race scenario: cpu0 cpu1 espintcp_close() cancel_work_sync(&ctx->work); espintcp_write_space() schedule_work(&ctx->work); To prevent this race condition, cancel_work_sync() is replaced with disable_work_sync().
CVE-2026-28789 High · 7.5 CWE-362 Mar 5, 2026
OliveTin: Unauthenticated DoS via concurrent map writes in OAuth2 state handling
OliveTin gives access to predefined shell commands from a web interface. Prior to version 3000.10.3, an unauthenticated denial-of-service vulnerability exists in OliveTin’s OAuth2 login flow. Concurrent requests to /oauth/login can trigger unsynchronized access to a shared registeredStates map, causing a Go runtime panic (fatal error: concurrent map writes) and process termination. This allows remote attackers to crash the service when OAuth2 is enabled. This issue has been patched in version 3000.10.3.
CVE-2026-28551 Medium · 4.7 CWE-362 Mar 5, 2026
Race Condition in Huawei Harmonyos
Race condition vulnerability in the device security management module. Impact: Successful exploitation of this vulnerability may affect availability.
CVE-2026-28549 Medium · 4.7 CWE-362 Mar 5, 2026
Race Condition in Huawei Harmonyos
Race condition vulnerability in the permission management service. Impact: Successful exploitation of this vulnerability may affect availability.
CVE-2026-28550 Medium · 4.7 CWE-362 Mar 5, 2026
Race Condition in Huawei Harmonyos
Race condition vulnerability in the security control module. Impact: Successful exploitation of this vulnerability may affect availability.
CVE-2026-28545 Medium · 4.7 CWE-362 Mar 5, 2026
Race Condition in Huawei Harmonyos
Race condition vulnerability in the printing module. Impact: Successful exploitation of this vulnerability may affect availability.
CVE-2026-28544 Medium · 4.7 CWE-362 Mar 5, 2026
Race Condition in Huawei Harmonyos
Race condition vulnerability in the printing module. Impact: Successful exploitation of this vulnerability may affect availability.
CVE-2026-28543 Medium · 4.7 CWE-362 Mar 5, 2026
Race Condition in Huawei Harmonyos
Race condition vulnerability in the maintenance and diagnostics module. Impact: Successful exploitation of this vulnerability may affect availability.
CVE-2026-25674 Low · 3.7 CWE-362 Mar 3, 2026
Potential incorrect permissions on newly created file system objects
An issue was discovered in 6.0 before 6.0.3, 5.2 before 5.2.12, and 4.2 before 4.2.29. Race condition in file-system storage and file-based cache backends in Django allows an attacker to cause file system objects to be created with incorrect permissions via concurrent requests, where one thread's temporary `umask` change affects other threads in multi-threaded environments. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Tarek Nakkouch for reporting this issue.
CVE-2025-48641 High · 7.0 CWE-362 Mar 2, 2026
Race Condition in Google Android
In multiple functions of Nfc.h, there is a possible use after free 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.
CVE-2025-48577 High · 7.4 CWE-362 Mar 2, 2026
Race Condition in Google Android
In multiple functions of KeyguardViewMediator.java, there is a possible lockscreen bypass 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.
CVE-2025-48568 High · 7.4 CWE-362 Mar 2, 2026
Race Condition in Google Android
In multiple locations, there is a possible lockscreen bypass 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.
CVE-2026-0995 Low · 3.6 CWE-362 Mar 2, 2026
Race Condition in Arm C1-pro Firmware
An issue has been identified in Arm C1-Pro before r1p2-50eac0, where, under certain conditions, a TLBI+DSB might fail to ensure the completion of memory accesses related to SME.
CVE-2026-2802 Medium · 4.2 CWE-362 Feb 24, 2026
Race condition in the JavaScript: GC component
Race condition in the JavaScript: GC component. This vulnerability was fixed in Firefox 148 and Thunderbird 148.
CVE-2026-27189 Medium · 5.8 CWE-362 Feb 20, 2026
OpenSift: Race-prone local persistence could cause state corruption/loss
OpenSift is an AI study tool that sifts through large datasets using semantic search and generative AI. Versions 1.1.2-alpha and below, use non-atomic and insufficiently synchronized local JSON persistence flows, potentially causing concurrent operations to lose updates or corrupt local state across sessions/study/quiz/flashcard/wellness/auth stores. This issue has been fixed in version 1.1.3-alpha.
CVE-2026-26201 High · 7.5 CWE-362 Feb 19, 2026
emp3r0r Affected by Concurrent Map Access DoS (panic/crash)
emp3r0r is a C2 designed by Linux users for Linux environments. Prior to version 3.21.2, multiple shared maps are accessed without consistent synchronization across goroutines. Under concurrent activity, Go runtime can trigger `fatal error: concurrent map read and map write`, causing C2 process crash (availability loss). Version 3.21.2 fixes this issue.
CVE-2026-23230 Medium · 5.5 CWE-362 Feb 18, 2026
smb: client: split cached_fid bitfields to avoid shared-byte RMW races
In the Linux kernel, the following vulnerability has been resolved: smb: client: split cached_fid bitfields to avoid shared-byte RMW races is_open, has_lease and on_list are stored in the same bitfield byte in struct cached_fid but are updated in different code paths that may run concurrently. Bitfield assignments generate byte read–modify–write operations (e.g. `orb $mask, addr` on x86_64), so updating one flag can restore stale values of the others. A possible interleaving is: CPU1: load old byte (has_lease=1, on_list=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | IS_OPEN) -> reintroduces cleared bits To avoid this class of races, convert these flags to separate bool fields.
CVE-2025-71235 Medium · 5.5 CWE-362 Feb 18, 2026
scsi: qla2xxx: Delay module unload while fabric scan in progress
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Delay module unload while fabric scan in progress System crash seen during load/unload test in a loop. [105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086 [105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0 [105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000 [105954.384923] FS: 0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000 [105954.384925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0 [105954.384928] PKRU: 55555554 [105954.384929] Call Trace: [105954.384931] <IRQ> [105954.384934] qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx] [105954.384962] ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx] [105954.384980] ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx] [105954.384999] ? __wake_up_common+0x80/0x190 [105954.385004] ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx] [105954.385023] ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx] [105954.385040] ? __handle_irq_event_percpu+0x3d/0x190 [105954.385044] ? handle_irq_event+0x58/0xb0 [105954.385046] ? handle_edge_irq+0x93/0x240 [105954.385050] ? __common_interrupt+0x41/0xa0 [105954.385055] ? common_interrupt+0x3e/0xa0 [105954.385060] ? asm_common_interrupt+0x22/0x40 The root cause of this was that there was a free (dma_free_attrs) in the interrupt context. There was a device discovery/fabric scan in progress. A module unload was issued which set the UNLOADING flag. As part of the discovery, after receiving an interrupt a work queue was scheduled (which involved a work to be queued). Since the UNLOADING flag is set, the work item was not allocated and the mapped memory had to be freed. The free occurred in interrupt context leading to system crash. Delay the driver unload until the fabric scan is complete to avoid the crash.
CVE-2026-23207 Medium · 4.7 CWE-362 Feb 14, 2026
spi: tegra210-quad: Protect curr_xfer check in IRQ handler
In the Linux kernel, the following vulnerability has been resolved: spi: tegra210-quad: Protect curr_xfer check in IRQ handler Now that all other accesses to curr_xfer are done under the lock, protect the curr_xfer NULL check in tegra_qspi_isr_thread() with the spinlock. Without this protection, the following race can occur: CPU0 (ISR thread) CPU1 (timeout path) ---------------- ------------------- if (!tqspi->curr_xfer) // sees non-NULL spin_lock() tqspi->curr_xfer = NULL spin_unlock() handle_*_xfer() spin_lock() t = tqspi->curr_xfer // NULL! ... t->len ... // NULL dereference! With this patch, all curr_xfer accesses are now properly synchronized. Although all accesses to curr_xfer are done under the lock, in tegra_qspi_isr_thread() it checks for NULL, releases the lock and reacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer(). There is a potential for an update in between, which could cause a NULL pointer dereference. To handle this, add a NULL check inside the handlers after acquiring the lock. This ensures that if the timeout path has already cleared curr_xfer, the handler will safely return without dereferencing the NULL pointer.
CVE-2025-71221 High · 7.0 CWE-362 Feb 14, 2026
dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue()
In the Linux kernel, the following vulnerability has been resolved: dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue() Add proper locking in mmp_pdma_residue() to prevent use-after-free when accessing descriptor list and descriptor contents. The race occurs when multiple threads call tx_status() while the tasklet on another CPU is freeing completed descriptors: CPU 0 CPU 1 ----- ----- mmp_pdma_tx_status() mmp_pdma_residue() -> NO LOCK held list_for_each_entry(sw, ..) DMA interrupt dma_do_tasklet() -> spin_lock(&desc_lock) list_move(sw->node, ...) spin_unlock(&desc_lock) | dma_pool_free(sw) <- FREED! -> access sw->desc <- UAF! This issue can be reproduced when running dmatest on the same channel with multiple threads (threads_per_chan > 1). Fix by protecting the chain_running list iteration and descriptor access with the chan->desc_lock spinlock.