deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-39vw-qp34-rmwf
Package: serde_yaml (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: >= 0.6.0-rc1, < 0.8.4
Patched in: 0.8.4

Summary: Uncontrolled recursion leads to abort in deserialization

Details:
Affected versions of this crate did not properly check for recursion while deserializing aliases. This allows an attacker to make a YAML file with an alias referring to itself causing an abort. The flaw was corrected by checking the recursion depth.
GitHub Security Advisory: GHSA-gwfj-pw2x-h6c2
Package: simd-json (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: >= 0.1.13, < 0.1.15
Patched in: 0.1.15

Summary: Out of bounds read in simd-json

Details:
The affected version of this crate did not guard against accessing memory beyond the range of its input data. A pointer cast to read the data into a 256-bit register could lead to a segmentation fault when the end plus the 32 bytes (256 bit) read would overlap into the next page during string parsing. This allows an attacker to eventually crash a service. The flaw was corrected by using a padding buffer for the last read from the input. So that we are we never read over the boundary of the input data.
GitHub Security Advisory: GHSA-rxr4-x558-x7hw
Package: smallvec (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-415: Double Free
Vulnerable versions: >= 0.3.2, < 0.6.3
Patched in: 0.6.3

Summary: Double free in smallvec

Details:
If an iterator passed to SmallVec::insert_many panicked in Iterator::next, destructors were run during unwinding while the vector was in an inconsistent state, possibly causing a double free (a destructor running on two copies of the same value).

This is fixed in smallvec 0.6.3 by ensuring that the vector's length is not updated to include moved items until they have been removed from their original positions. Items may now be leaked if Iterator::next panics, but they will not be dropped more than once.
GitHub Security Advisory: GHSA-mm7v-vpv8-xfc3
Package: smallvec (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-415: Double Free
Vulnerable versions: >= 0.6.5, < 0.6.10
Patched in: 0.6.10

Summary: Double free in smallvec

Details:
Attempting to call grow on a spilled SmallVec with a value equal to the current capacity causes it to free the existing data. This performs a double free immediately and may lead to use-after-free on subsequent accesses to the SmallVec contents. An attacker that controls the value passed to grow may exploit this flaw to obtain memory contents or gain remote code execution.
GitHub Security Advisory: GHSA-83r8-p8v6-6gfm
Package: slock (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: < 0.2.0
Patched in: 0.2.0

Summary: Slock<T> allows sending non-Send types across thread boundaries

Details:
`Slock<T>` unconditionally implements `Send`/`Sync`.

Affected versions of this crate allows sending non-Send types to other threads,
which can lead to data races and memory corruption due to the data race.
GitHub Security Advisory: GHSA-hv7x-f3pv-gpwr
Package: spin (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-662: Improper Synchronization
Vulnerable versions: < 0.5.2
Patched in: 0.5.2

Summary: Wrong memory orderings violates mutual exclusion in spin

Details:
Wrong memory orderings inside the RwLock implementation allow for two writers to acquire the lock at the same time. The drop implementation used Ordering::Relaxed, which allows the compiler or CPU to reorder a mutable access on the locked data after the lock has been yielded.

Only users of the RwLock implementation are affected. Users of Once (including users of lazy_static with the spin_no_std feature enabled) are NOT affected.

On strongly ordered CPU architectures like x86, the only real way that this would lead to a memory corruption is if the compiler reorders an access after the lock is yielded, which is possible but in practice unlikely. It is a more serious issue on weakly ordered architectures such as ARM which, except in the presence of certain instructions, allow the hardware to decide which accesses are seen at what times. Therefore on an ARM system it is likely that using the wrong memory ordering would result in a memory corruption, even if the compiler itself doesn't reorder the memory accesses in a buggy way.
GitHub Security Advisory: GHSA-8mjx-h23h-w2pg
Package: stack_dst (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-415: Double Free
Vulnerable versions: < 0.6.1
Patched in: 0.6.1

Summary: Double free in stack_dst

Details:
Affected versions of stack_dst used a push_inner function that increased the internal length of the array and then called val.clone(). If the val.clone() call panics, the stack could drop an already dropped element or drop uninitialized memory. This issue was fixed in `2a4d538` by increasing the length of the array after elements are cloned.
GitHub Security Advisory: GHSA-8q2v-67v7-6vc6
Package: rocket (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: >= 0.4.0, < 0.4.5
Patched in: 0.4.5

Summary: Data races in rocket

Details:
The affected version of rocket contains a Clone trait implementation of LocalRequest that reuses the pointer to inner Request object. This causes data race in rare combinations of APIs if the original and the cloned objects are modified at the same time.
GitHub Security Advisory: GHSA-6q5w-m3c5-rv95
Package: rusqlite (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: < 0.23.0
Patched in: 0.23.0

Summary: Data races in rusqlite

Details:
An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via VTab / VTabCursor.
GitHub Security Advisory: GHSA-28ph-f7gx-fqj8
Package: rusqlite (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: < 0.23.0
Patched in: 0.23.0

Summary: Data races in rusqlite

Details:
An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via create_module.
GitHub Security Advisory: GHSA-3cgf-9m6x-pwwr
Package: rusqlite (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: < 0.23.0
Patched in: 0.23.0

Summary: Data races in rusqlite

Details:
An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via UnlockNotification.
GitHub Security Advisory: GHSA-8r7q-r9mx-35rh
Package: rusqlite (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-134: Use of Externally-Controlled Format String
Vulnerable versions: < 0.23.0
Patched in: 0.23.0

Summary: Mishandling of format strings in rusqlite

Details:
An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated because rusqlite::trace::log mishandles format strings.
GitHub Security Advisory: GHSA-rjh8-p66p-jrh5
Package: rusqlite (RUST)
Severity: HIGH (CVSS 8.1)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: < 0.23.0
Patched in: 0.23.0

Summary: Data races in rusqlite

Details:
An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via an Auxdata API data race.
GitHub Security Advisory: GHSA-87xh-9q6h-r5cc
Package: rusqlite (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.26.0, < 0.26.2
Patched in: 0.26.2

Summary: Use After Free in rusqlite

Details:
An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_window_function has a use-after-free.
GitHub Security Advisory: GHSA-87xh-9q6h-r5cc
Package: rusqlite (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.25.0, < 0.25.4
Patched in: 0.25.4

Summary: Use After Free in rusqlite

Details:
An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_window_function has a use-after-free.
GitHub Security Advisory: GHSA-f6f2-3w33-54r9
Package: rusqlite (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.26.0, < 0.26.2
Patched in: 0.26.2

Summary: Use After Free in rusqlite

Details:
An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_aggregate_function has a use-after-free.
GitHub Security Advisory: GHSA-f6f2-3w33-54r9
Package: rusqlite (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.25.0, < 0.25.4
Patched in: 0.25.4

Summary: Use After Free in rusqlite

Details:
An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_aggregate_function has a use-after-free.
GitHub Security Advisory: GHSA-969w-q74q-9j8v
Package: secp256k1 (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.24.0, < 0.24.2
Patched in: 0.24.2

Summary: Unsound API in `secp256k1` allows use-after-free and invalid deallocation from safe code

Details:
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.
GitHub Security Advisory: GHSA-969w-q74q-9j8v
Package: secp256k1 (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.23.0, < 0.23.5
Patched in: 0.23.5

Summary: Unsound API in `secp256k1` allows use-after-free and invalid deallocation from safe code

Details:
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.
GitHub Security Advisory: GHSA-969w-q74q-9j8v
Package: secp256k1 (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 0.14.0, < 0.22.2
Patched in: 0.22.2

Summary: Unsound API in `secp256k1` allows use-after-free and invalid deallocation from safe code

Details:
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.
GitHub Security Advisory: GHSA-q89g-4vhh-mvvm
Package: rusqlite (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: >= 0.25.0, < 0.25.4
Patched in: 0.25.4

Summary: Incorrect Lifetime Bounds on Closures in `rusqlite`

Details:
The lifetime bound on several closure-accepting `rusqlite` functions (specifically, functions which register a callback to be later invoked by SQLite) was too relaxed. If a closure referencing borrowed values on the stack is was passed to one of these functions, it could allow Rust code to access objects on the stack after they have been dropped.

The impacted functions are:

- Under `cfg(feature = "functions")`: `Connection::create_scalar_function`, `Connection::create_aggregate_function` and `Connection::create_window_function`.
- Under `cfg(feature = "hooks")`: `Connection::commit_hook`, `Connection::rollback_hook` and `Connection::update_hook`.
- Under `cfg(feature = "collation")`: `Connection::create_collation`.

The issue exists in all `0.25.*` versions prior to `0.25.4`, and all `0.26.*` versions prior to 0.26.2 (specifically: `0.25.0`, `0.25.1`, `0.25.2`, `0.25.3`, `0.26.0`, and `0.26.1`).

The fix is available in versions `0.26.2` and newer, and also has been back-ported to `0.25.4`. As it does not exist in `0.24.*`, all affected versions should have an upgrade path to a semver-compatible release.
GitHub Security Advisory: GHSA-q89g-4vhh-mvvm
Package: rusqlite (RUST)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: >= 0.26.0, < 0.26.2
Patched in: 0.26.2

Summary: Incorrect Lifetime Bounds on Closures in `rusqlite`

Details:
The lifetime bound on several closure-accepting `rusqlite` functions (specifically, functions which register a callback to be later invoked by SQLite) was too relaxed. If a closure referencing borrowed values on the stack is was passed to one of these functions, it could allow Rust code to access objects on the stack after they have been dropped.

The impacted functions are:

- Under `cfg(feature = "functions")`: `Connection::create_scalar_function`, `Connection::create_aggregate_function` and `Connection::create_window_function`.
- Under `cfg(feature = "hooks")`: `Connection::commit_hook`, `Connection::rollback_hook` and `Connection::update_hook`.
- Under `cfg(feature = "collation")`: `Connection::create_collation`.

The issue exists in all `0.25.*` versions prior to `0.25.4`, and all `0.26.*` versions prior to 0.26.2 (specifically: `0.25.0`, `0.25.1`, `0.25.2`, `0.25.3`, `0.26.0`, and `0.26.1`).

The fix is available in versions `0.26.2` and newer, and also has been back-ported to `0.25.4`. As it does not exist in `0.24.*`, all affected versions should have an upgrade path to a semver-compatible release.
GitHub Security Advisory: GHSA-3qm2-rfqw-fmrw
Package: scratchpad (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-415: Double Free
Vulnerable versions: < 1.3.1
Patched in: 1.3.1

Summary: move_elements can double-free objects on panic

Details:
Affected versions of scratchpad used ptr::read to read elements while calling a user provided function f on them. Since the pointer read duplicates ownership, a panic inside the user provided f function could cause a double free when unwinding.

The flaw was fixed in commit `891561bea` by removing the unsafe block and using a plain iterator.
GitHub Security Advisory: GHSA-mh6h-f25p-98f8
Package: protobuf (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 2.6.0
Patched in: 2.6.0

Summary: Uncontrolled memory consumption in protobuf

Details:
Affected versions of this crate called Vec::reserve() on user-supplied input. This allows an attacker to cause an Out of Memory condition while calling the vulnerable method on untrusted data.
GitHub Security Advisory: GHSA-w7j2-35mf-95p7
Package: rand_core (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-330: Use of Insufficiently Random Values
Vulnerable versions: >= 0.6.0, < 0.6.2
Patched in: 0.6.2

Summary: Incorrect check on buffer length in rand_core

Details:
An issue was discovered in the rand_core crate before 0.6.2 for Rust. Because `read_u32_into` and `read_u64_into` mishandle certain buffer-length checks, a random number generator may be seeded with too little data. The vulnerability was introduced in v0.6.0. The advisory doesn't apply to earlier minor version numbers.

Because read_u32_into and read_u64_into mishandle certain buffer-length checks, a random number generator may be seeded with too little data.
GitHub Security Advisory: GHSA-vhfr-v4w9-45v8
Package: renderdoc (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 0.5.0
Patched in: 0.5.0

Summary: Improper Input Validation in renderdoc

Details:
Affected versions of this crate exposed several methods which took self by immutable reference, despite the requesting the RenderDoc API to set a mutable value internally. This is technically unsound and calling these methods from multiple threads without synchronization could lead to unexpected and unpredictable behavior. The flaw was corrected in release 0.5.0.
GitHub Security Advisory: GHSA-g4rw-8m5q-6453
Package: rgb (RUST)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer, CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: >= 0.5.4, < 0.8.20
Patched in: 0.8.20

Summary: Out of bounds access in rgb

Details:
Affected versions of rgb crate allow viewing and modifying data of any type T wrapped in RGB<T> as bytes, and do not correctly constrain RGB<T> and other wrapper structures to the types for which it is safe to do so.

Safety violation possible for a type wrapped in RGB<T> and similar wrapper structures:

* If T contains padding, viewing it as bytes may lead to exposure of contents of uninitialized memory.
* If T contains a pointer, modifying it as bytes may lead to dereferencing of arbitrary pointers.
* Any safety and/or validity invariants for T may be violated.

The issue was resolved by requiring all types wrapped in structures provided by RGB crate to implement an unsafe marker trait.
GitHub Security Advisory: GHSA-24g6-5rx7-58wj
Package: pnet (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-909: Missing Initialization of Resource
Vulnerable versions: < 0.27.2
Patched in: 0.27.2

Summary: Missing Initialization of Resource in pnet

Details:
An issue was discovered in the pnet crate before 0.27.2 for Rust. There is a segmentation fault (upon attempted dereference of an uninitialized descriptor) because of an erroneous IcmpTransportChannelIterator compiler optimization.
GitHub Security Advisory: GHSA-w428-f65r-h4q2
Package: raw-cpuid (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 3.1.0, < 9.1.1
Patched in: 9.1.1

Summary: Deserialization of Untrusted Data in rust-cpuid

Details:
An issue was discovered in the raw-cpuid crate before 9.1.1 for Rust. If the serialize feature is used (which is not the the default), a Deserialize operation may lack sufficient validation, leading to memory corruption or a panic.
GitHub Security Advisory: GHSA-g4w7-3qr8-5623
Package: rusqlite (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-351: Insufficient Type Distinction
Vulnerable versions: < 0.23.0
Patched in: 0.23.0

Summary: Improper type usage in rusqlite

Details:
An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated via the repr(Rust) type.
GitHub Security Advisory: GHSA-g4g4-3pqw-8m7f
Package: rusqlite (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.26.0, < 0.26.2
Patched in: 0.26.2

Summary: Use After Free in rusqlite

Details:
An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. rollback_hook has a use-after-free.
GitHub Security Advisory: GHSA-g4g4-3pqw-8m7f
Package: rusqlite (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.25.0, < 0.25.4
Patched in: 0.25.4

Summary: Use After Free in rusqlite

Details:
An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. rollback_hook has a use-after-free.
GitHub Security Advisory: GHSA-q3cc-7p7g-392c
Package: rusqlite (RUST)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-416: Use After Free
Vulnerable versions: < 0.23.0
Patched in: 0.23.0

Summary: Use after free in rusqlite

Details:
An issue was discovered in the rusqlite crate before 0.23.0 for Rust. Memory safety can be violated because sessions.rs has a use-after-free.
GitHub Security Advisory: GHSA-4qr3-m7ww-hh9g
Package: rusqlite (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.26.0, < 0.26.2
Patched in: 0.26.2

Summary: Use After Free in rusqlite

Details:
An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. commit_hook has a use-after-free.
GitHub Security Advisory: GHSA-4qr3-m7ww-hh9g
Package: rusqlite (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: >= 0.25.0, < 0.25.4
Patched in: 0.25.4

Summary: Use After Free in rusqlite

Details:
An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. commit_hook has a use-after-free.