Spotted what might be an issue in api/Cargo.lock around line 134.
The vulnerability is real. Crossbeam‑utils <0.8.7 assumes {i,u}64 values are always aligned like Atomic{I,U}64. On 32‑bit targets the alignment can be smaller, causing unaligned memory accesses and data races when fetch_* is used on AtomicCell<{i,u}64>. Impact includes crashes, memory corruption, and race conditions – a high‑severity risk for any code using those atomics on 32‑bit platforms. Upgrading to crossbeam‑utils 0.8.7 or later fixes the alignment check.
Something like this might fix it:
--- a/api/Cargo.lock
+++ b/api/Cargo.lock
@@ -135,7 +135,7 @@
[[package]]
name = "crossbeam-utils"
-version = "0.7.2"
+version = "0.8.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "..."
For reference: rule CVE-2022-23639. Rated high.
I have not run the test suite here, so treat the suggestion as a starting point rather than something ready to merge.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
Spotted what might be an issue in
api/Cargo.lockaround line 134.The vulnerability is real. Crossbeam‑utils <0.8.7 assumes
{i,u}64values are always aligned likeAtomic{I,U}64. On 32‑bit targets the alignment can be smaller, causing unaligned memory accesses and data races whenfetch_*is used onAtomicCell<{i,u}64>. Impact includes crashes, memory corruption, and race conditions – a high‑severity risk for any code using those atomics on 32‑bit platforms. Upgrading to crossbeam‑utils 0.8.7 or later fixes the alignment check.Something like this might fix it:
For reference: rule
CVE-2022-23639. Rated high.I have not run the test suite here, so treat the suggestion as a starting point rather than something ready to merge.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.