# GHSA-p75v-367r-2v23: `cell-project` used incorrect variance when projecting through `&Cell` > A Rust library vulnerability allows memory corruption via incorrect variance handling, potentially leading to code execution. - **Severity:** Not scored - **Exploited in the wild:** Not known - **Login needed:** Not needed - **Attackable:** Not stated - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 27 Aug 2020 - **Also known as:** RUSTSEC-2020-0164 ## What is GHSA-p75v-367r-2v23? GHSA-p75v-367r-2v23 is a memory corruption vulnerability in cell-project, published on 27 Aug 2020. ### Official description ## Overview The issue lies in the implementation of the `cell_project` macro which used `field as *const _` instead of `field as *mut _`. The problem being that `*const T` is covariant in `T` while `*mut T` is invariant in `T`. Keep in mind that `&Cell` is invariant in `T`, so casting to `*const T` relaxed the variance, and lead to unsoundness, as shown in the example below. ```rs use std::cell::Cell; use cell_project::cell_project as cp; struct Foo<'a> { x: Option<&'a Cell>>, } impl<'a> Drop for Foo<'a> { fn drop(&mut self) { // `ourselves` is an &Cell. // NB: `Drop` is unsound. if let Some(ourselves) = self.x.as_ref() { // replace `self` (but this doesn't actually replace `self`) let is_x_none = ourselves.replace(Foo { x: None, }).x.as_ref().is_none(); // if we just moved out of `self`, and we had a `Some` originally, // how come this is a `None`? if is_x_none { println!("how did we get a None?"); } } } } fn main() { let foo = Cell::new(Foo { x: None, }); let x = cp!(Foo<'_>, foo.x); x.set(Some(&foo)); } ``` ### MIRI error ```rs $ cargo +nightly miri run Finished dev [unoptimized + debuginfo] target(s) in 0.01s Running `` error: Undefined Behavior: not granting access to tag because incompatible item is protected: [Unique for <2472> (call 796)] --> $RUST_STD_PATH/src/rust/library/core/src/cell.rs:404:31 | 404 | mem::replace(unsafe { &mut *self.value.get() }, val) | ^^^^^^^^^^^^^^^^^^^^^^ not granting access to tag because incompatible item is protected: [Unique for <2472> (call 796)] | = help: this indicates a potential bug in the program: it performed an invalid operation, but the rules it violated are still experimental = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information = note: inside `std::cell::Cell::::replace` at $RUST_STD_PATH/src/rust/library/core/src/cell.rs:404:31 note: inside `::drop` at src/main.rs:14:29 --> src/main.rs:14:29 | 14 | let is_x_none = ourselves.replace(Foo { | _____________________________^ 15 | | x: None, 16 | | }).x.as_ref().is_none(); | |______________^ = note: inside `std::ptr::drop_in_place:: - shim(Some(Foo))` at $RUST_STD_PATH/src/rust/library/core/src/ptr/mod.rs:486:1 = note: inside `std::ptr::drop_in_place::> - shim(Some(std::cell::UnsafeCell))` at $RUST_STD_PATH/src/rust/library/core/src/ptr/mod.rs:486:1 = note: inside `std::ptr::drop_in_place::> - shim(Some(std::cell::Cell))` at $RUST_STD_PATH/src/rust/library/core/src/ptr/mod.rs:486:1 note: inside `main` at src/main.rs:32:1 --> src/main.rs:32:1 | 32 | } | ^ note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace error: aborting due to previous error ``` ## Affected Versions All versions of the cell-project crate before `0.1.4` are affected. ## Mitigation This was fixed in [Issues/4], and released as version `0.1.4`. So just updating to the latest version will include the fix (which may result in a compile error on unsound usage). ## Acknowledgements This was discovered and fixed by [@SoniEx2](https://github.com/SoniEx2) in cell-project: [Issues/3] and [Issues/4] [issues/3]: https://github.com/RustyYato/cell-project/issues/3 [issues/4]: https://github.com/RustyYato/cell-project/issues/4 ## Which versions are affected by GHSA-p75v-367r-2v23? 3 open source packages ship an affected version, including cell-project. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `cell-project` | crates.io | All versions | 0.1.4 | | `cell-project` | crates.io | All versions | 0.1.4 | | `cell-project` | crates.io | From 0.0.0-0 | 0.1.4 | ## How do I fix GHSA-p75v-367r-2v23? Upgrade cell-project to 0.1.4 or later. ## Is GHSA-p75v-367r-2v23 being exploited? There is no known exploitation of GHSA-p75v-367r-2v23 in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for GHSA-p75v-367r-2v23 and fix it if it is affected. What it is: GHSA-p75v-367r-2v23 is a memory corruption vulnerability in cell-project, published on 27 Aug 2020. Exploitation: There is no known exploitation of GHSA-p75v-367r-2v23 in the wild and no public exploit code. Affected packages and fixed versions: - cell-project (crates.io): affected all versions; fixed in 0.1.4 - cell-project (crates.io): affected all versions; fixed in 0.1.4 - cell-project (crates.io): affected from 0.0.0-0; fixed in 0.1.4 Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/GHSA-p75v-367r-2v23/ (Markdown: https://insights.sbomify.com/GHSA-p75v-367r-2v23/index.md) ``` ## Sources - OSV: https://osv.dev/vulnerability/GHSA-p75v-367r-2v23 --- From sbomify Insights: https://insights.sbomify.com/GHSA-p75v-367r-2v23/ Summaries are generated and may contain mistakes; the official description above is the record.