Vulnerabilities > Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

DATE CVE VULNERABILITY TITLE RISK
2024-04-17 CVE-2023-52645 Race Condition vulnerability in Linux Kernel
In the Linux kernel, the following vulnerability has been resolved: pmdomain: mediatek: fix race conditions with genpd If the power domains are registered first with genpd and *after that* the driver attempts to power them on in the probe sequence, then it is possible that a race condition occurs if genpd tries to power them on in the same time. The same is valid for powering them off before unregistering them from genpd. Attempt to fix race conditions by first removing the domains from genpd and *after that* powering down domains. Also first power up the domains and *after that* register them to genpd.
local
high complexity
linux CWE-362
4.7
2024-04-17 CVE-2024-26910 Race Condition vulnerability in Linux Kernel
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix performance regression in swap operation The patch "netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test", commit 28628fa9 fixes a race condition. But the synchronize_rcu() added to the swap function unnecessarily slows it down: it can safely be moved to destroy and use call_rcu() instead. Eric Dumazet pointed out that simply calling the destroy functions as rcu callback does not work: sets with timeout use garbage collectors which need cancelling at destroy which can wait.
local
high complexity
linux CWE-362
4.7
2024-03-08 CVE-2024-23275 Race Condition vulnerability in Apple Macos
A race condition was addressed with additional validation.
local
high complexity
apple CWE-362
4.7
2024-02-27 CVE-2021-46925 Race Condition vulnerability in Linux Kernel
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix kernel panic caused by race of smc_sock A crash occurs when smc_cdc_tx_handler() tries to access smc_sock but smc_release() has already freed it. [ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88 [ 4570.696048] #PF: supervisor write access in kernel mode [ 4570.696728] #PF: error_code(0x0002) - not-present page [ 4570.697401] PGD 0 P4D 0 [ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111 [ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0 [ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30 <...> [ 4570.711446] Call Trace: [ 4570.711746] <IRQ> [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0 [ 4570.712470] smc_wr_tx_tasklet_fn+0x213/0x560 [ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10 [ 4570.713489] tasklet_action_common.isra.17+0x66/0x140 [ 4570.714083] __do_softirq+0x123/0x2f4 [ 4570.714521] irq_exit_rcu+0xc4/0xf0 [ 4570.714934] common_interrupt+0xba/0xe0 Though smc_cdc_tx_handler() checked the existence of smc connection, smc_release() may have already dismissed and released the smc socket before smc_cdc_tx_handler() further visits it. smc_cdc_tx_handler() |smc_release() if (!conn) | | |smc_cdc_tx_dismiss_slots() | smc_cdc_tx_dismisser() | |sock_put(&smc->sk) <- last sock_put, | smc_sock freed bh_lock_sock(&smc->sk) (panic) | To make sure we won't receive any CDC messages after we free the smc_sock, add a refcount on the smc_connection for inflight CDC message(posted to the QP but haven't received related CQE), and don't release the smc_connection until all the inflight CDC messages haven been done, for both success or failed ones. Using refcount on CDC messages brings another problem: when the link is going to be destroyed, smcr_link_clear() will reset the QP, which then remove all the pending CQEs related to the QP in the CQ.
local
high complexity
linux CWE-362
4.7
2024-02-21 CVE-2024-26583 Race Condition vulnerability in Linux Kernel
In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires.
local
high complexity
linux CWE-362
4.7
2024-02-21 CVE-2024-26585 Race Condition vulnerability in Linux Kernel
In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do.
local
high complexity
linux CWE-362
4.7
2024-02-06 CVE-2024-24255 Race Condition vulnerability in Dronecode PX4 Drone Autopilot
A Race Condition discovered in geofence.cpp and mission_feasibility_checker.cpp in PX4 Autopilot 1.14 and earlier allows attackers to send drones on unintended missions.
network
high complexity
dronecode CWE-362
4.2
2024-02-06 CVE-2024-24254 Race Condition vulnerability in Dronecode PX4 Drone Autopilot
PX4 Autopilot 1.14 and earlier, due to the lack of synchronization mechanism for loading geofence data, has a Race Condition vulnerability in the geofence.cpp and mission_feasibility_checker.cpp.
network
high complexity
dronecode CWE-362
4.2
2024-02-05 CVE-2024-24858 Race Condition vulnerability in Linux Kernel
A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}_{min,max}_interval_set() function.
high complexity
linux CWE-362
5.3
2024-02-05 CVE-2024-24859 Race Condition vulnerability in Linux Kernel
A race condition was found in the Linux kernel's net/bluetooth in sniff_{min,max}_interval_set() function.
high complexity
linux CWE-362
4.8