CWE-362
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
ClassDraftLikelihood: Medium
Description
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Hierarchy (View 1000)
Related attack patterns (CAPEC)
CAPEC-26 · CAPEC-29
CVEs mapped to this weakness (767)
page 3 of 39| CVE | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2016-4309 | Hig | 0.53 | 7.5 | 0.19 | Jun 30, 2016 | Session fixation vulnerability in Symphony CMS 2.6.7, when session.use_only_cookies is disabled, allows remote attackers to hijack web sessions via the PHPSESSID parameter. | |
| CVE-2016-1757 | Hig | 0.53 | 7.0 | 0.50 | Mar 24, 2016 | Race condition in the kernel in Apple iOS before 9.3 and OS X before 10.11.4 allows attackers to execute arbitrary code in a privileged context via a crafted app. | |
| CVE-2016-0858 | Hig | 0.53 | 8.1 | 0.01 | Jan 15, 2016 | Race condition in Advantech WebAccess before 8.1 allows remote attackers to execute arbitrary code or cause a denial of service (buffer overflow) via a crafted request. | |
| CVE-2024-51505 | Hig | 0.52 | 8.0 | 0.00 | Feb 18, 2025 | An issue was discovered in Atos Eviden IDRA before 2.7.1. A highly trusted role (Config Admin) could leverage a race condition to escalate privileges. | |
| CVE-2026-34351 | Hig | 0.51 | 7.8 | 0.00 | May 12, 2026 | Concurrent execution using shared resource with improper synchronization ('race condition') in Windows TCP/IP allows an authorized attacker to elevate privileges locally. | |
| CVE-2026-34337 | Hig | 0.51 | 7.8 | 0.00 | May 12, 2026 | Use after free in Windows Cloud Files Mini Filter Driver allows an authorized attacker to elevate privileges locally. | |
| CVE-2026-34334 | Hig | 0.51 | 7.8 | 0.00 | May 12, 2026 | Concurrent execution using shared resource with improper synchronization ('race condition') in Windows TCP/IP allows an authorized attacker to elevate privileges locally. | |
| CVE-2026-7432 | Hig | 0.51 | 7.8 | 0.00 | May 12, 2026 | A race condition in Ivanti Secure Access Client before 22.8R6 allows a locally authenticated user to escalate privileges to SYSTEM | |
| CVE-2026-43353 | Hig | 0.51 | 7.8 | 0.00 | May 8, 2026 | In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Fix race in DMA ring dequeue The HCI DMA dequeue path (hci_dma_dequeue_xfer()) may be invoked for multiple transfers that timeout around the same time. However, the function is not serialized and can race with itself. When a timeout occurs, hci_dma_dequeue_xfer() stops the ring, processes incomplete transfers, and then restarts the ring. If another timeout triggers a parallel call into the same function, the two instances may interfere with each other - stopping or restarting the ring at unexpected times. Add a mutex so that hci_dma_dequeue_xfer() is serialized with respect to itself. | |
| CVE-2026-43116 | Hig | 0.51 | 7.8 | 0.00 | May 6, 2026 | In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: ensure safe access to master conntrack Holding reference on the expectation is not sufficient, the master conntrack object can just go away, making exp->master invalid. To access exp->master safely: - Grab the nf_conntrack_expect_lock, this gets serialized with clean_from_lists() which also holds this lock when the master conntrack goes away. - Hold reference on master conntrack via nf_conntrack_find_get(). Not so easy since the master tuple to look up for the master conntrack is not available in the existing problematic paths. This patch goes for extending the nf_conntrack_expect_lock section to address this issue for simplicity, in the cases that are described below this is just slightly extending the lock section. The add expectation command already holds a reference to the master conntrack from ctnetlink_create_expect(). However, the delete expectation command needs to grab the spinlock before looking up for the expectation. Expand the existing spinlock section to address this to cover the expectation lookup. Note that, the nf_ct_expect_iterate_net() calls already grabs the spinlock while iterating over the expectation table, which is correct. The get expectation command needs to grab the spinlock to ensure master conntrack does not go away. This also expands the existing spinlock section to cover the expectation lookup too. I needed to move the netlink skb allocation out of the spinlock to keep it GFP_KERNEL. For the expectation events, the IPEXP_DESTROY event is already delivered under the spinlock, just move the delivery of IPEXP_NEW under the spinlock too because the master conntrack event cache is reached through exp->master. While at it, add lockdep notations to help identify what codepaths need to grab the spinlock. | |
| CVE-2026-43023 | Hig | 0.51 | 7.8 | 0.00 | May 1, 2026 | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: fix race conditions in sco_sock_connect() sco_sock_connect() checks sk_state and sk_type without holding the socket lock. Two concurrent connect() syscalls on the same socket can both pass the check and enter sco_connect(), leading to use-after-free. The buggy scenario involves three participants and was confirmed with additional logging instrumentation: Thread A (connect): HCI disconnect: Thread B (connect): sco_sock_connect(sk) sco_sock_connect(sk) sk_state==BT_OPEN sk_state==BT_OPEN (pass, no lock) (pass, no lock) sco_connect(sk): sco_connect(sk): hci_dev_lock hci_dev_lock hci_connect_sco <- blocked -> hcon1 sco_conn_add->conn1 lock_sock(sk) sco_chan_add: conn1->sk = sk sk->conn = conn1 sk_state=BT_CONNECT release_sock hci_dev_unlock hci_dev_lock sco_conn_del: lock_sock(sk) sco_chan_del: sk->conn=NULL conn1->sk=NULL sk_state= BT_CLOSED SOCK_ZAPPED release_sock hci_dev_unlock (unblocked) hci_connect_sco -> hcon2 sco_conn_add -> conn2 lock_sock(sk) sco_chan_add: sk->conn=conn2 sk_state= BT_CONNECT // zombie sk! release_sock hci_dev_unlock Thread B revives a BT_CLOSED + SOCK_ZAPPED socket back to BT_CONNECT. Subsequent cleanup triggers double sock_put() and use-after-free. Meanwhile conn1 is leaked as it was orphaned when sco_conn_del() cleared the association. Fix this by: - Moving lock_sock() before the sk_state/sk_type checks in sco_sock_connect() to serialize concurrent connect attempts - Fixing the sk_type != SOCK_SEQPACKET check to actually return the error instead of just assigning it - Adding a state re-check in sco_connect() after lock_sock() to catch state changes during the window between the locks - Adding sco_pi(sk)->conn check in sco_chan_add() to prevent double-attach of a socket to multiple connections - Adding hci_conn_drop() on sco_chan_add failure to prevent HCI connection leaks | |
| CVE-2026-31761 | Hig | 0.51 | 7.8 | 0.00 | May 1, 2026 | In the Linux kernel, the following vulnerability has been resolved: iio: gyro: mpu3050: Move iio_device_register() to correct location iio_device_register() should be at the end of the probe function to prevent race conditions. Place iio_device_register() at the end of the probe function and place iio_device_unregister() accordingly. | |
| CVE-2026-31700 | Hig | 0.51 | 7.8 | 0.00 | May 1, 2026 | In the Linux kernel, the following vulnerability has been resolved: net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd() In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points directly into the mmap'd TX ring buffer shared with userspace. The kernel validates the header via __packet_snd_vnet_parse() but then re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent userspace thread can modify the vnet_hdr fields between validation and use, bypassing all safety checks. The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr to a stack-local variable. All other vnet_hdr consumers in the kernel (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX path is the only caller of virtio_net_hdr_to_skb() that reads directly from user-controlled shared memory. Fix this by copying vnet_hdr from the mmap'd ring buffer to a stack-local variable before validation and use, consistent with the approach used in packet_snd() and all other callers. | |
| CVE-2026-31516 | Hig | 0.51 | 7.8 | 0.00 | Apr 22, 2026 | In the Linux kernel, the following vulnerability has been resolved: xfrm: prevent policy_hthresh.work from racing with netns teardown A XFRM_MSG_NEWSPDINFO request can queue the per-net work item policy_hthresh.work onto the system workqueue. The queued callback, xfrm_hash_rebuild(), retrieves the enclosing struct net via container_of(). If the net namespace is torn down before that work runs, the associated struct net may already have been freed, and xfrm_hash_rebuild() may then dereference stale memory. xfrm_policy_fini() already flushes policy_hash_work during teardown, but it does not synchronize policy_hthresh.work. Synchronize policy_hthresh.work in xfrm_policy_fini() as well, so the queued work cannot outlive the net namespace teardown and access a freed struct net. | |
| CVE-2026-32165 | Hig | 0.51 | 7.8 | 0.00 | Apr 14, 2026 | Use after free in Windows User Interface Core allows an authorized attacker to elevate privileges locally. | |
| CVE-2026-32164 | Hig | 0.51 | 7.8 | 0.00 | Apr 14, 2026 | Concurrent execution using shared resource with improper synchronization ('race condition') in Windows User Interface Core allows an authorized attacker to elevate privileges locally. | |
| CVE-2026-32163 | Hig | 0.51 | 7.8 | 0.00 | Apr 14, 2026 | Concurrent execution using shared resource with improper synchronization ('race condition') in Windows User Interface Core allows an authorized attacker to elevate privileges locally. | |
| CVE-2026-32160 | Hig | 0.51 | 7.8 | 0.00 | Apr 14, 2026 | Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Push Notifications allows an authorized attacker to elevate privileges locally. | |
| CVE-2026-32159 | Hig | 0.51 | 7.8 | 0.00 | Apr 14, 2026 | Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Push Notifications allows an authorized attacker to elevate privileges locally. | |
| CVE-2026-32158 | Hig | 0.51 | 7.8 | 0.00 | Apr 14, 2026 | Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Push Notifications allows an authorized attacker to elevate privileges locally. |