Loading story…
A soundness flaw in the Rust cgmath crate allows Matrix2::swap_columns, Matrix3::swap_columns, and Matrix4::swap_columns to trigger undefined behavior from safe Rust code when callers pass identical column indices. The affected implementations in cgmath 0.18.0 use std::ptr::swap on two mutable references derived from the same matrix when inputs such as m.swap_columns(0, 0) are supplied, violating Rust aliasing guarantees and creating a memory-corruption risk.
The issue was documented in RustSec as RUSTSEC-2026-0197 and reproduced with proof-of-concept examples and Miri diagnostics showing a Stacked Borrows violation inside std::ptr::swap. No patched release was listed in the advisory, though the reported fix is straightforward: return early when both indices are equal before performing the swap, and apply that guard consistently across the Matrix2, Matrix3, and Matrix4 implementations.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
A GitHub issue was opened against rustgd/cgmath reporting that cgmath 0.18.0's Matrix2/3/4 swap_columns implementations can trigger undefined behavior when called with identical indices. The report included proof-of-concept examples, noted Miri reports a Stacked Borrows violation in std::ptr::swap, and proposed returning early when a == b.
RustSec published advisory RUSTSEC-2026-0197 for the cgmath crate, describing a soundness issue in Matrix2::swap_columns, Matrix3::swap_columns, and Matrix4::swap_columns where identical indices can trigger undefined behavior from safe Rust code. The advisory states no patched version is available and notes a minimal remediation would be to return early when both indices are equal.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
github.com
Open sourcerustsec.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A memory-corruption vulnerability in the Rust crate **`metacall`** allows a bad-free to be triggered through the safe public API **`MetaCallException::new()`**. The flaw affects crate version **`0.5.10`** and stems from passing the address of a stack-allocated Rust exception structure into C code, then later wrapping that pointer while the destructor still treats it as heap memory and frees it. RustSec assigned the issue **`RUSTSEC-2026-0156`**, warning that simply creating and dropping a `MetaCallException` can cause invalid memory deallocation without requiring callers to use unsafe Rust. A related vulnerability report published in the `metacall/core` repository said AddressSanitizer reproduces the crash in `exception_destroy` and traced the root cause to storing a pointer to Rust stack memory while an internal `leak` flag remains `false`, causing `Drop` to free an invalid pointer. The same report flagged broader unsoundness in the crate, including shallow-copy `Clone` implementations over raw pointers and a safe `new_raw` API that accepts arbitrary raw pointers and dereferences C memory. No patched version was listed in the advisory, and the reporter recommended heap-allocating structures passed to C and marking raw-pointer constructors unsafe or otherwise restricting them.
Jun 29, 2026
Two high-severity vulnerabilities were disclosed in **rust-openssl**, the Rust bindings for OpenSSL, affecting multiple `0.9.x` and `0.10.x` releases prior to **`0.10.78`**. **`CVE-2026-41898`** affects versions from `0.9.24` up to, but not including, `0.10.78`, where several FFI trampoline callback paths passed a closure-returned `usize` to OpenSSL without validating it against the output buffer size. The flaw can trigger buffer overflows and leak adjacent memory to a network peer, and it is mapped to **`CWE-126`** and **`CWE-130`**. A second issue, **`CVE-2026-41681`**, affects versions from `0.10.39` up to, but not including, `0.10.78`, in `MdCtxRef::digest_final()`, which writes `EVP_MD_CTX_size(ctx)` bytes to the caller buffer without checking whether the buffer is large enough. The resulting out-of-bounds write can cause stack corruption and is reachable from safe Rust, with the weakness classified as **`CWE-121`**. Both vulnerabilities were addressed in **`rust-openssl 0.10.78`**, with public advisories, code references, and fix details released alongside the CVE records.
Jun 29, 2026
Multiple vulnerabilities in the Rust serialization crate **rkyv** allow crafted untrusted archives to bypass validation in supposedly safe checked deserialization paths and trigger memory safety failures. RustSec advisories `RUSTSEC-2026-0233`, `RUSTSEC-2026-0234`, and `RUSTSEC-2026-0235` describe flaws that can lead to a heap use-after-free in `ArchivedString::deserialize`, out-of-bounds reads in archives containing hash tables, and out-of-bounds reads involving `Rc`/`Arc` shared pointers. Affected safe APIs include `rkyv::access` and `rkyv::from_bytes`, and the resulting impact includes process crashes, denial of service, and potential memory exposure when applications process attacker-controlled archive bytes. The issues were fixed in **rkyv 0.8.17**, which strengthens archive range validation, rejects malformed relative pointers and inconsistent hash table states, and hardens shared-pointer verification. An upstream code change shows the project now validates shared pointers using both erased data pointers and pointer metadata, explicitly detecting conflicting metadata such as forged slice lengths that reference the same memory region. The maintainers said the `0.7` series is also affected but unsupported, and advised users handling untrusted archives to upgrade to `0.8.17` or later.
Aug 4, 2026