VYPR

CWE-662

Improper Synchronization

ClassDraft

Description

The product utilizes multiple threads, processes, components, or systems to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.

Hierarchy (View 1000)

Related attack patterns (CAPEC)

CAPEC-25 · CAPEC-26 · CAPEC-27 · CAPEC-29

CVEs mapped to this weakness (27)

page 2 of 2
  • CVE-2020-36217Jan 22, 2021
    risk 0.00cvss epss 0.01

    An issue was discovered in the may_queue crate through 2020-11-10 for Rust. Because Queue does not have bounds on its Send trait or Sync trait, memory corruption can occur.

  • CVE-2020-36218Jan 22, 2021
    risk 0.00cvss epss 0.01

    An issue was discovered in the buttplug crate before 1.0.4 for Rust. ButtplugFutureStateShared does not properly consider (!Send|!Sync) objects, leading to a data race.

  • CVE-2020-36219Jan 22, 2021
    risk 0.00cvss epss 0.01

    An issue was discovered in the atomic-option crate through 2020-10-31 for Rust. Because AtomicOption implements Sync unconditionally, a data race can occur.

  • CVE-2020-36220Jan 22, 2021
    risk 0.00cvss epss 0.01

    An issue was discovered in the va-ts crate before 0.0.4 for Rust. Because Demuxer omits a required T: Send bound, a data race and memory corruption can occur.

  • CVE-2020-35927Dec 31, 2020
    risk 0.00cvss epss 0.00

    An issue was discovered in the thex crate through 2020-12-08 for Rust. Thex allows cross-thread data races of non-Send types.

  • CVE-2020-13759Jun 2, 2020
    risk 0.00cvss epss 0.02

    rust-vmm vm-memory before 0.1.1 and 0.2.x before 0.2.1 allows attackers to cause a denial of service (loss of IP networking) because read_obj and write_obj do not properly access memory. This affects aarch64 (with musl or glibc) and x86_64 (with musl).

  • CVE-2019-16137Sep 9, 2019
    risk 0.00cvss epss 0.01

    An issue was discovered in the spin crate before 0.5.2 for Rust, when RwLock is used. Because memory ordering is mishandled, two writers can acquire the lock at the same time, violating mutual exclusion.