The internal Channel type's Drop method has a race
which could, in some circumstances, lead to a double-free.
This could result in memory corruption.
Quoting from the
upstream description in merge request #1187:
> The problem lies in the fact that dicard_all_messages contained two paths that could lead to head.block being read but only one of them would swap the value. This meant that dicard_all_messages could end up observing a non-null block pointer (and therefore attempting to free it) without setting head.block to null. This would then lead to Channel::drop making a second attempt at dropping the same pointer.
The bug was introduced while fixing a memory leak, in
upstream MR #1084,
first published in 0.5.12.
The fix is in
upstream MR #1187
and has been published in 0.5.15
| Score | Percentile |
|---|---|
| 0.48% | 64.88% |
| Base score | Version | Severity | Vector |
|---|---|---|---|
| 6.3 | 4.0 | — |
|
| Type | Value |
|---|---|
| GHSA | GHSA-pg9f-39pc-qf8g ↗ |
| CVE | CVE-2025-4574 ↗ |
| CWE id | Name |
|---|---|
| CWE-415 | Double Free |
Vulnerable version ranges and first patched releases as published by GitHub.
| Ecosystem | Package | Vulnerable range | First patched | Vulnerable functions |
|---|---|---|---|---|
| rust | crossbeam-channel | >= 0.5.12, < 0.5.15 | 0.5.15 | — |