# GHSA-969w-q74q-9j8v: Unsound API in `secp256k1` allows use-after-free and invalid deallocation from safe code > An unsound API in the secp256k1 Rust library allows safe code to trigger use-after-free and invalid deallocation, potentially leading to crashes or 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:** 30 Nov 2022 - **Also known as:** RUSTSEC-2022-0070 ## What is GHSA-969w-q74q-9j8v? GHSA-969w-q74q-9j8v is an use after free vulnerability in secp256k1, published on 30 Nov 2022. ### Official description Because of incorrect bounds on method `Secp256k1::preallocated_gen_new` it was possible to cause use-after-free from safe consumer code. It was also possible to "free" memory not allocated by the appropriate allocator. The method takes a place for storing the context as a mutable reference and returns context containing that reference. Because the code internally uses `unsafe` and the bounds were incorrect it was possible to create a context that outlived the passed reference (e.g. `'static`). Because the context can alternatively carry heap-allocated pointer freed on drop it was possible to "deallocate" a pointer that wasn't returned from appropriate allocator. The code decides whether to free the memory based on type parameter but because of missing bound it was possible to construct the context with invalid parameter. You are unaffected if you either * don't call `Secp256k1::preallocated_gen_new` * manually checked that your usage of the method is sound * upgraded to the patched version of `secp256k1` (recommended) The patched version uses correct bounds which means it is API-breaking. This effectively means adopting the policy of Rust lang itself allowing API-breaking changes to fix soundness bugs. Note however that valid straigthforward usage of the code will continue to compile. Only unsound code or code that propagates the bound in custom generics will fail to compile. If the code is sound fixing the bounds should be sufficient to make the code compile. See the [GitHub issue](https://github.com/rust-bitcoin/rust-secp256k1/issues/543) for example "exploit" code and further discussion. ## Which versions are affected by GHSA-969w-q74q-9j8v? 7 open source packages ship an affected version, including secp256k1. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `secp256k1` | crates.io | From 0.14.0 | 0.22.2, 0.23.5, 0.24.2 | | `secp256k1` | crates.io | From 0.14.0 | 0.22.2 | | `secp256k1` | crates.io | From 0.14.0 | 0.22.2 | | `secp256k1` | crates.io | From 0.23.0 | 0.23.5 | | `secp256k1` | crates.io | From 0.23.0 | 0.23.5 | | `secp256k1` | crates.io | From 0.24.0 | 0.24.2 | | `secp256k1` | crates.io | From 0.24.0 | 0.24.2 | ## How do I fix GHSA-969w-q74q-9j8v? Upgrade secp256k1 to a fixed version for your release line: 0.22.2, 0.23.5 or 0.24.2. ## Is GHSA-969w-q74q-9j8v being exploited? There is no known exploitation of GHSA-969w-q74q-9j8v in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for GHSA-969w-q74q-9j8v and fix it if it is affected. What it is: GHSA-969w-q74q-9j8v is an use after free vulnerability in secp256k1, published on 30 Nov 2022. Exploitation: There is no known exploitation of GHSA-969w-q74q-9j8v in the wild and no public exploit code. Affected packages and fixed versions: - secp256k1 (crates.io): affected from 0.14.0; fixed in 0.22.2, 0.23.5, 0.24.2 - secp256k1 (crates.io): affected from 0.14.0; fixed in 0.22.2 - secp256k1 (crates.io): affected from 0.14.0; fixed in 0.22.2 - secp256k1 (crates.io): affected from 0.23.0; fixed in 0.23.5 - secp256k1 (crates.io): affected from 0.23.0; fixed in 0.23.5 - secp256k1 (crates.io): affected from 0.24.0; fixed in 0.24.2 - secp256k1 (crates.io): affected from 0.24.0; fixed in 0.24.2 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-969w-q74q-9j8v/ (Markdown: https://insights.sbomify.com/GHSA-969w-q74q-9j8v/index.md) ``` ## Sources - OSV: https://osv.dev/vulnerability/GHSA-969w-q74q-9j8v --- From sbomify Insights: https://insights.sbomify.com/GHSA-969w-q74q-9j8v/ Summaries are generated and may contain mistakes; the official description above is the record.