Weakness (CWE)
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization
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.
How to prevent it (8 mitigations)
-
Architecture and Design
In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
-
Architecture and Design
Use thread-safe capabilities such as the data access abstraction in Spring.
-
Architecture and Design
Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.
Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
-
Implementation
When using multithreading and operating on shared variables, only use thread-safe functions.
-
Implementation
Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
-
Implementation
Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
-
Implementation
Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
-
Implementation
Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
Source: MITRE CWE-362
870 results · Clear filters · Feed
-
High 7.0
Windows ALPC Elevation of Privilege Vulnerability
Windows ALPC Elevation of Privilege Vulnerability
-
High 7.8CVE-2021-44731 Public exploit
snapd could be made to escalate privileges and run programs as administrator
A race condition existed in the snapd 2.54.2 snap-confine binary when preparing a private mount namespace for a snap. This could allow a local attacker to gain root privileges by bind-mounting their own contents inside the snap's private mount namespace and c…
-
High 8.1
Improper Restriction of Operations within the Bounds of a Memory Buffer and Race Condition in crossbeam-utils
crossbeam-utils provides atomics, synchronization primitives, scoped threads, and other utilities for concurrent programming in Rust. crossbeam-utils prior to version 0.8.7 incorrectly assumed that the alignment of `{i,u}64` was always the same as `Atomic{I,U…
-
High 8.1
AtomicBucket<T> unconditionally implements Send/Sync
An issue was discovered in the metrics-util crate before 0.7.0 for Rust. There is a data race and memory corruption because AtomicBucket<T> unconditionally implements the Send and Sync traits.
-
High 8.1
Race Condition in tokio
An issue was discovered in the tokio crate before 1.8.4, and 1.9.x through 1.13.x before 1.13.1, for Rust. In certain circumstances involving a closed oneshot channel, there is a data race and memory corruption.
-
High 8.1
Data race in ruspiro-singleton
An issue was discovered in the ruspiro-singleton crate before 0.4.1 for Rust. In Singleton, Send and Sync do not have bounds checks.
-
High 8.1
Data races in unicycle
An issue was discovered in the unicycle crate before 0.7.1 for Rust. PinSlab<T> and Unordered<T, S> do not have bounds on their Send and Sync traits.
-
High 8.1
Data race in conqueue
An issue was discovered in the conqueue crate before 0.4.0 for Rust. There are unconditional implementations of Send and Sync for QueueSender<T>.
-
High 8.1
Data race in tiny_future
An issue was discovered in the tiny_future crate before 0.4.0 for Rust. Future<T> does not have bounds on its Send and Sync traits.
-
High 8.1
Data races in ticketed_lock
An issue was discovered in the ticketed_lock crate before 0.3.0 for Rust. There are unconditional implementations of Send for ReadTicket<T> and WriteTicket<T>.
-
High 8.1
Data races in libsbc
An issue was discovered in the libsbc crate before 0.1.5 for Rust. For Decoder<R>, it implements Send for any R: Read.
-
High 8.1
Data race in abox
An issue was discovered in the abox crate before 0.4.1 for Rust. It implements Send and Sync for AtomicBox<T> with no requirement for T: Send and T: Sync.
-
High 8.1
Data races in beef
An issue was discovered in the beef crate before 0.5.0 for Rust. beef::Cow has no Sync bound on its Send trait.
-
High 8.1
Data races in async-coap
An issue was discovered in the async-coap crate through 2020-12-08 for Rust. Send and Sync are implemented for ArcGuard<RC, T> without trait bounds on RC.
-
High 8.1
Data races in convec
An issue was discovered in the convec crate through 2020-11-24 for Rust. There are unconditional implementations of Send and Sync for ConVec<T>.
-
High 8.1
Data races in signal-simple
An issue was discovered in the signal-simple crate through 2020-11-15 for Rust. There are unconditional implementations of Send and Sync for SyncChannel<T>.
-
High 8.1
Data race in v9
An issue was discovered in the v9 crate through 2020-12-18 for Rust. There is an unconditional implementation of Sync for SyncRef<T>.
-
High 8.1
Data races in cache
An issue was discovered in the cache crate through 2020-11-24 for Rust. There are unconditional implementations of Send and Sync for Cache<K>.
-
High 8.1
Data races in bunch
An issue was discovered in the bunch crate through 2020-11-12 for Rust. There are unconditional implementations of Send and Sync for Bunch<T>.
-
High 8.1
Data races in rcu_cell
An issue was discovered in the rcu_cell crate through 2020-11-14 for Rust. There are unconditional implementations of Send and Sync for RcuCell<T>.
-
High 8.1
Data races in scottqueue
An issue was discovered in the scottqueue crate through 2020-11-15 for Rust. There are unconditional implementations of Send and Sync for Queue<T>.
-
High 8.1
Data races in parc
An issue was discovered in the parc crate through 2020-11-14 for Rust. LockWeak<T> has an unconditional implementation of Send without trait bounds on T.
-
High 8.1
Slock<T> allows sending non-Send types across thread boundaries
An issue was discovered in the slock crate through 2020-11-17 for Rust. Slock<T> unconditionally implements Send and Sync.
-
High 8.1
Data races in toolshed
An issue was discovered in the toolshed crate through 2020-11-15 for Rust. In CopyCell<T>, the Send trait lacks bounds on the contained type.
-
High 8.1
Data races in lever
An issue was discovered in the lever crate before 0.1.1 for Rust. AtomicBox<T> implements the Send and Sync traits for all types T.
-
High 8.1
Data races in lexer
An issue was discovered in the lexer crate through 2020-11-10 for Rust. For ReaderResult<T, E>, there is an implementation of Sync with a trait bound of T: Send, E: Send.
-
High 8.1
Data races in dces
An issue was discovered in the dces crate through 2020-12-09 for Rust. The World type is marked as Send but lacks bounds on its EntityStore and ComponentStore.
-
High 8.1
Data races in model
An issue was discovered in the model crate through 2020-11-10 for Rust. The Shared data structure has an implementation of the Send and Sync traits without regard for the inner type.
-
High 8.1
Data races in noise_search
An issue was discovered in the noise_search crate through 2020-12-10 for Rust. There are unconditional implementations of Send and Sync for MvccRwLock.
-
High 8.1
Data race in syncpool
An issue was discovered in the syncpool crate before 0.1.6 for Rust. There is an unconditional implementation of Send for Bucket2.
-
High 8.1
Data races in multiqueue
An issue was discovered in the multiqueue crate through 2020-12-25 for Rust. There are unconditional implementations of Send for InnerSend<RW, T>, InnerRecv<RW, T>, FutInnerSend<RW, T>, and FutInnerRecv<RW, T>.
-
High 7.5
Race Condition Vulnerability in Phoenix Contact FL SWITCH SMCS series products
In Phoenix Contact FL SWITCH SMCS series products in multiple versions if an attacker sends a hand-crafted TCP-Packet with the Urgent-Flag set and the Urgent-Pointer set to 0, the network stack will crash. The device needs to be rebooted afterwards.
-
High 7.6CVE-2021-30465 EPSS 10%
mount destinations can be swapped via symlink-exchange to cause mounts outside the rootfs
runc before 1.0.0-rc95 allows a Container Filesystem Breakout via Directory Traversal. To exploit the vulnerability, an attacker must be able to create multiple containers with a fairly specific mount configuration. The problem occurs via a symlink-exchange a…
-
High 7.5
Junos OS: PTX Series, QFX10K Series: A PTX/QFX FPC may restart unexpectedly with the "inline-Jflow" feature enabled on a large-scale deployment
On PTX Series and QFX10k Series devices with the "inline-jflow" feature enabled, a use after free weakness in the Packet Forwarding Engine (PFE) microkernel architecture of Juniper Networks Junos OS may allow an attacker to cause a Denial of Service (DoS) con…
-
High 8.8
Data race in audio in Google Chrome prior to 89.0.4389.72 allowed a remote attacker to potentially exploit heap corrupt…
KEV Nov 3, 2021 -
High 7.0
Improper synchronization in Apache Netbeans HTML/Java API
There exists a race condition between the deletion of the temporary file and the creation of the temporary directory in `webkit` subproject of HTML/Java API version 1.7. A similar vulnerability has recently been disclosed in other Java projects and the fix in…
-
High 8.1
Use after free in internment
An issue was discovered in the internment crate through 2020-05-28 for Rust. ArcIntern::drop has a race condition and resultant use-after-free.
-
High 8.1
Data races in rocket
An issue was discovered in the rocket crate before 0.4.5 for Rust. LocalRequest::clone creates more than one mutable references to the same object, possibly causing a data race.
-
High 8.3
Junos OS: MX Series: Services card might restart due to a race condition when DNS filtering is enabled.
When DNS filtering is enabled on Juniper Networks Junos MX Series with one of the following cards MS-PIC, MS-MIC or MS-MPC, an incoming stream of packets processed by the Multiservices PIC Management Daemon (mspmand) process might be bypassed due to a race co…
-
High 8.3
Junos OS: MX Series: Receipt of specific packets can cause services card to restart when DNS filtering is configured.
When DNS filtering is enabled on Juniper Networks Junos MX Series with one of the following cards MS-PIC, MS-MIC or MS-MPC, an incoming stream of packets processed by the Multiservices PIC Management Daemon (mspmand) process, responsible for managing "URL Fil…