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 (768)
page 15 of 39| CVE | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2025-43292 | Med | 0.36 | 5.5 | 0.00 | Sep 15, 2025 | A race condition was addressed with improved state handling. This issue is fixed in macOS Sequoia 15.7, macOS Sequoia 15.7.2, macOS Tahoe 26. An app may be able to access sensitive user data. | |
| CVE-2025-52993 | Med | 0.36 | 5.6 | 0.00 | Jun 27, 2025 | A race condition in the Nix, Lix, and Guix package managers enables changing the ownership of arbitrary files to the UID and GID of the build user (e.g., nixbld* or guixbuild*). This affects Nix before 2.24.15, 2.26.4, 2.28.4, and 2.29.1; Lix before 2.91.2, 2.92.2, and 2.93.1; and Guix before 1.4.0-38.0e79d5b. | |
| CVE-2024-36285 | Med | 0.36 | 5.6 | 0.00 | Feb 12, 2025 | Race condition in some Intel(R) PROSet/Wireless WiFi and Killerâ„¢ WiFi software for Windows before version 23.80 may allow an authenticated user to potentially enable denial of service via local access. | |
| CVE-2024-12747 | Med | 0.36 | 5.6 | 0.00 | Jan 14, 2025 | A flaw was found in rsync. This vulnerability arises from a race condition during rsync's handling of symbolic links. Rsync's default behavior when encountering symbolic links is to skip them. If an attacker replaced a regular file with a symbolic link at the right time, it was possible to bypass the default behavior and traverse symbolic links. Depending on the privileges of the rsync process, an attacker could leak sensitive information, potentially leading to privilege escalation. | |
| CVE-2024-27876 | Med | 0.36 | 5.5 | 0.00 | Sep 17, 2024 | A race condition was addressed with improved locking. This issue is fixed in iOS 17.7 and iPadOS 17.7, iOS 18 and iPadOS 18, macOS Sequoia 15, macOS Sonoma 14.7, macOS Ventura 13.7, visionOS 2. Unpacking a maliciously crafted archive may allow an attacker to write arbitrary files. | |
| CVE-2024-36894 | Med | 0.36 | 5.6 | 0.00 | May 30, 2024 | In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete FFS based applications can utilize the aio_cancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following: DWC3 Gadget FFS Application dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue() There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (io_data->req) the FFS application is also referencing it for the usb_ep_dequeue() call. This can lead to accessing a stale/hanging pointer. commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") relocated the usb_ep_free_request() into ffs_epfile_async_io_complete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffs_epfile_async_io_complete(), as usb_ep_dequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock. Fix this issue by moving the usb_ep_free_request() back to ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req to NULL after freeing it within the ffs->eps_lock. This resolves the race condition above, as the ffs_aio_cancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffs_user_copy_work() not freeing the USB request until the AIO cancel is done referencing it. This fix depends on commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") | |
| CVE-2024-35898 | Med | 0.36 | 5.5 | 0.00 | May 19, 2024 | In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process. | |
| CVE-2024-26960 | Med | 0.36 | 5.5 | 0.00 | May 1, 2024 | In the Linux kernel, the following vulnerability has been resolved: mm: swap: fix race between free_swap_and_cache() and swapoff() There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map. This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below). Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache(). Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this): --8<----- __swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE". swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0. So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped(). Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries. Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry. Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.] Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap(). __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries); What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()? --8<----- | |
| CVE-2017-15038 | Med | 0.36 | 5.6 | 0.00 | Oct 10, 2017 | Race condition in the v9fs_xattrwalk function in hw/9pfs/9p.c in QEMU (aka Quick Emulator) allows local guest OS users to obtain sensitive information from host heap memory via vectors related to reading extended attributes. | |
| CVE-2017-14483 | Med | 0.36 | 5.5 | 0.00 | Sep 15, 2017 | flower.initd in the Gentoo dev-python/flower package before 0.9.1-r1 for Celery Flower sets PID file ownership to a non-root account, which might allow local users to kill arbitrary processes by leveraging access to this non-root account for PID file modification before a root script executes a "kill `cat /pathname`" command. | |
| CVE-2017-14317 | Med | 0.36 | 5.6 | 0.00 | Sep 12, 2017 | A domain cleanup issue was discovered in the C xenstore daemon (aka cxenstored) in Xen through 4.9.x. When shutting down a VM with a stubdomain, a race in cxenstored may cause a double-free. The xenstored daemon may crash, resulting in a DoS of any parts of the system relying on it (including domain creation / destruction, ballooning, device changes, etc.). | |
| CVE-2017-5986 | Med | 0.36 | 5.5 | 0.01 | Feb 18, 2017 | Race condition in the sctp_wait_for_sndbuf function in net/sctp/socket.c in the Linux kernel before 4.9.11 allows local users to cause a denial of service (assertion failure and panic) via a multithreaded application that peels off an association in a certain buffer-full state. | |
| CVE-2016-7916 | Med | 0.36 | 5.5 | 0.00 | Nov 16, 2016 | Race condition in the environ_read function in fs/proc/base.c in the Linux kernel before 4.5.4 allows local users to obtain sensitive information from kernel memory by reading a /proc/*/environ file during a process-setup time interval in which environment-variable copying is incomplete. | |
| CVE-2016-1807 | Med | 0.36 | 5.1 | 0.00 | May 20, 2016 | Race condition in the Disk Images subsystem in Apple iOS before 9.3.2, OS X before 10.11.5, tvOS before 9.2.1, and watchOS before 2.2.1 allows local users to obtain sensitive information from kernel memory via unspecified vectors. | |
| CVE-2015-7550 | Med | 0.36 | 5.5 | 0.00 | Feb 8, 2016 | The keyctl_read_key function in security/keys/keyctl.c in the Linux kernel before 4.3.4 does not properly use a semaphore, which allows local users to cause a denial of service (NULL pointer dereference and system crash) or possibly have unspecified other impact via a crafted application that leverages a race condition between keyctl_revoke and keyctl_read calls. | |
| CVE-2013-0266 | Med | 0.36 | 5.5 | 0.00 | Mar 8, 2013 | A flaw was found in the `puppetlabs-cinder` module, as used in PackStack. This vulnerability is due to incorrect file permissions, specifically world-readable permissions, on the `cinder.conf` and `api-paste.ini` configuration files. A local user can exploit this by reading these files, which leads to the disclosure of OpenStack administrative passwords. This information disclosure could allow unauthorized access to sensitive OpenStack resources. | |
| CVE-2016-9962 | Med | 0.35 | 6.4 | 0.00 | Jan 31, 2017 | RunC allowed additional container processes via 'runc exec' to be ptraced by the pid 1 of the container. This allows the main processes of the container, if running as root, to gain access to file-descriptors of these new processes during the initialization and can lead to container escapes or modification of runC state before the process is fully placed inside the container. | |
| CVE-2016-4247 | Med | 0.35 | 5.3 | 0.01 | Jul 13, 2016 | Race condition in Adobe Flash Player before 18.0.0.366 and 19.x through 22.x before 22.0.0.209 on Windows and OS X and before 11.2.202.632 on Linux allows attackers to obtain sensitive information via unspecified vectors. | |
| CVE-2016-1670 | Med | 0.35 | 5.3 | 0.01 | May 14, 2016 | Race condition in the ResourceDispatcherHostImpl::BeginRequest function in content/browser/loader/resource_dispatcher_host_impl.cc in Google Chrome before 50.0.2661.102 allows remote attackers to make arbitrary HTTP requests by leveraging access to a renderer process and reusing a request ID. | |
| CVE-2026-7960 | Med | 0.34 | 5.3 | 0.00 | May 6, 2026 | Race in Speech in Google Chrome prior to 148.0.7778.96 allowed a remote attacker who had compromised the renderer process to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium) |