CVE Vulnerabilities

CVE-2021-32810

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

Published: Aug 02, 2021 | Modified: Nov 21, 2024
CVSS 3.x
9.8
CRITICAL
Source:
NVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.x
6.8 MEDIUM
AV:N/AC:M/Au:N/C:P/I:P/A:P
RedHat/V2
RedHat/V3
9.8 MODERATE
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Ubuntu
MEDIUM
root.io logo minimus.io logo echo.ai logo

crossbeam-deque is a package of work-stealing deques for building task schedulers when programming in Rust. In versions prior to 0.7.4 and 0.8.0, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using Stealer::steal, Stealer::steal_batch, or Stealer::steal_batch_and_pop are affected by this issue. This has been fixed in crossbeam-deque 0.8.1 and 0.7.4.

Weakness

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.

Affected Software

NameVendorStart VersionEnd Version
CrossbeamCrossbeam_project*0.7.4 (excluding)
CrossbeamCrossbeam_project0.8.0 (including)0.8.1 (excluding)
Red Hat Enterprise Linux 7RedHatfirefox-0:91.2.0-4.el7_9*
Red Hat Enterprise Linux 7RedHatthunderbird-0:91.2.0-1.el7_9*
Red Hat Enterprise Linux 8RedHatfirefox-0:91.2.0-4.el8_4*
Red Hat Enterprise Linux 8RedHatthunderbird-0:91.2.0-1.el8_4*
Red Hat Enterprise Linux 8.1 Extended Update SupportRedHatfirefox-0:91.2.0-4.el8_1*
Red Hat Enterprise Linux 8.1 Extended Update SupportRedHatthunderbird-0:91.2.0-1.el8_1*
Red Hat Enterprise Linux 8.2 Extended Update SupportRedHatfirefox-0:91.2.0-4.el8_2*
Red Hat Enterprise Linux 8.2 Extended Update SupportRedHatthunderbird-0:91.2.0-1.el8_2*
FirefoxUbuntubionic*
FirefoxUbuntudevel*
FirefoxUbuntufocal*
FirefoxUbuntuhirsute*
FirefoxUbuntuimpish*
FirefoxUbuntujammy*
FirefoxUbuntukinetic*
FirefoxUbuntulunar*
FirefoxUbuntumantic*
FirefoxUbuntunoble*
FirefoxUbuntuoracular*
FirefoxUbuntuplucky*
FirefoxUbuntuquesting*
FirefoxUbuntutrusty*
FirefoxUbuntuxenial*
Rust-crossbeam-dequeUbuntufocal*
Rust-crossbeam-dequeUbuntuhirsute*
Rust-crossbeam-dequeUbuntuimpish*
Rust-crossbeam-dequeUbuntukinetic*
Rust-crossbeam-dequeUbuntutrusty*
Rust-crossbeam-dequeUbuntuupstream*
Rust-crossbeam-dequeUbuntuxenial*

Extended Description

A race condition occurs within concurrent environments, and it is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc. A race condition violates these properties, which are closely related:

A race condition exists when an “interfering code sequence” can still access the shared resource, violating exclusivity. The interfering code sequence could be “trusted” or “untrusted.” A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product.

Potential Mitigations

  • 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).

References