CWE-787
Allowed-with-ReviewOut-of-bounds Write
Abstraction: Base · Status: Draft
The product writes data past the end, or before the beginning, of the intended buffer.
15386 vulnerabilities reference this CWE, most recent first.
GHSA-6M3C-9C9Q-F5W3
Vulnerability from github – Published: 2023-02-12 06:30 – Updated: 2023-02-22 18:30In wlan driver, there is a possible missing params check. This could lead to local denial of service in wlan services.
{
"affected": [],
"aliases": [
"CVE-2022-42783"
],
"database_specific": {
"cwe_ids": [
"CWE-122",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-12T04:15:00Z",
"severity": "MODERATE"
},
"details": "In wlan driver, there is a possible missing params check. This could lead to local denial of service in wlan services.",
"id": "GHSA-6m3c-9c9q-f5w3",
"modified": "2023-02-22T18:30:34Z",
"published": "2023-02-12T06:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-42783"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1621031430231134210"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6M3H-MJM6-FJW7
Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-06-29 00:00Stack overflow vulnerability in parse_statement_list Cesanta MJS 1.20.1, allows remote attackers to cause a Denial of Service (DoS) via a crafted file.
{
"affected": [],
"aliases": [
"CVE-2020-36369"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-28T21:15:00Z",
"severity": "MODERATE"
},
"details": "Stack overflow vulnerability in parse_statement_list Cesanta MJS 1.20.1, allows remote attackers to cause a Denial of Service (DoS) via a crafted file.",
"id": "GHSA-6m3h-mjm6-fjw7",
"modified": "2022-06-29T00:00:32Z",
"published": "2022-05-24T19:03:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36369"
},
{
"type": "WEB",
"url": "https://github.com/cesanta/mjs/issues/135"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6M3J-WCQ6-V4JR
Vulnerability from github – Published: 2024-10-30 00:31 – Updated: 2025-02-03 18:30A maliciously crafted MODEL file when parsed in libodxdll.dll through Autodesk AutoCAD can force an Out-of-Bound Write vulnerability. A malicious actor can leverage this vulnerability to cause a crash, write sensitive data, or execute arbitrary code in the context of the current process.
{
"affected": [],
"aliases": [
"CVE-2024-8596"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-29T22:15:07Z",
"severity": "HIGH"
},
"details": "A maliciously crafted MODEL file when parsed in libodxdll.dll through Autodesk AutoCAD can force an Out-of-Bound Write vulnerability. A malicious actor can leverage this vulnerability to cause a crash, write sensitive data, or execute arbitrary code in the context of the current process.",
"id": "GHSA-6m3j-wcq6-v4jr",
"modified": "2025-02-03T18:30:38Z",
"published": "2024-10-30T00:31:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8596"
},
{
"type": "WEB",
"url": "https://autodesk.com/trust/security-advisories/adsk-sa-2024-0019"
},
{
"type": "WEB",
"url": "https://www.autodesk.com/trust/security-advisories/adsk-sa-2024-0019"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6M47-C6Q4-33VQ
Vulnerability from github – Published: 2022-12-23 21:30 – Updated: 2025-04-15 06:30D-Link DIR-882 DIR882A1_FW130B06 was discovered to contain a stack overflow via the Password parameter in the SetWanSettings module.
{
"affected": [],
"aliases": [
"CVE-2022-46561"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-23T19:15:00Z",
"severity": "HIGH"
},
"details": "D-Link DIR-882 DIR882A1_FW130B06 was discovered to contain a stack overflow via the Password parameter in the SetWanSettings module.",
"id": "GHSA-6m47-c6q4-33vq",
"modified": "2025-04-15T06:30:33Z",
"published": "2022-12-23T21:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46561"
},
{
"type": "WEB",
"url": "https://hackmd.io/%400dayResearch/SetWanSettings_L2TP"
},
{
"type": "WEB",
"url": "https://hackmd.io/%400dayResearch/SetWanSettings_PPPoE"
},
{
"type": "WEB",
"url": "https://hackmd.io/%400dayResearch/SetWanSettings_PPTP"
},
{
"type": "WEB",
"url": "https://hackmd.io/%400dayResearch/ry55QVQvj"
},
{
"type": "WEB",
"url": "https://hackmd.io/@0dayResearch/SetWanSettings_L2TP"
},
{
"type": "WEB",
"url": "https://hackmd.io/@0dayResearch/SetWanSettings_PPPoE"
},
{
"type": "WEB",
"url": "https://hackmd.io/@0dayResearch/SetWanSettings_PPTP"
},
{
"type": "WEB",
"url": "https://hackmd.io/@0dayResearch/ry55QVQvj"
},
{
"type": "WEB",
"url": "https://www.dlink.com/en/security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6M48-4C69-4G6C
Vulnerability from github – Published: 2022-05-24 17:29 – Updated: 2022-05-24 17:29U.S. Air Force Sensor Data Management System extract75 has a buffer overflow that leads to code execution. An overflow in a global variable (sBuffer) leads to a Write-What-Where outcome. Writing beyond sBuffer will clobber most global variables until reaching a pointer such as DES_info or image_info. By controlling that pointer, one achieves an arbitrary write when its fields are assigned. The data written is from a potentially untrusted NITF file in the form of an integer. The attacker can gain control of the instruction pointer.
{
"affected": [],
"aliases": [
"CVE-2020-13995"
],
"database_specific": {
"cwe_ids": [
"CWE-120",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-25T13:15:00Z",
"severity": "CRITICAL"
},
"details": "U.S. Air Force Sensor Data Management System extract75 has a buffer overflow that leads to code execution. An overflow in a global variable (sBuffer) leads to a Write-What-Where outcome. Writing beyond sBuffer will clobber most global variables until reaching a pointer such as DES_info or image_info. By controlling that pointer, one achieves an arbitrary write when its fields are assigned. The data written is from a potentially untrusted NITF file in the form of an integer. The attacker can gain control of the instruction pointer.",
"id": "GHSA-6m48-4c69-4g6c",
"modified": "2022-05-24T17:29:33Z",
"published": "2022-05-24T17:29:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13995"
},
{
"type": "WEB",
"url": "https://www.riverloopsecurity.com/blog/2020/09/nitf-extract75-cve-2020-13995"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6M4R-88FW-VCJ4
Vulnerability from github – Published: 2022-05-14 02:15 – Updated: 2022-05-14 02:15The ActiveX control in Adobe Flash Player before 10.3.183.15 and 11.x before 11.1.102.62 on Windows allows attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2012-0751"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-02-16T19:55:00Z",
"severity": "HIGH"
},
"details": "The ActiveX control in Adobe Flash Player before 10.3.183.15 and 11.x before 11.1.102.62 on Windows allows attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors.",
"id": "GHSA-6m4r-88fw-vcj4",
"modified": "2022-05-14T02:15:25Z",
"published": "2022-05-14T02:15:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-0751"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A14985"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2012-02/msg00014.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/48265"
},
{
"type": "WEB",
"url": "http://www.adobe.com/support/security/bulletins/apsb12-03.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6M57-8R3P-PQX6
Vulnerability from github – Published: 2026-05-29 19:05 – Updated: 2026-06-12 19:31Summary
Sender::send in src/lib.rs contains an unsafe block in the DISCONNECTED arm that transmutes a raw pointer (*mut Producer<T>) into the bytes of a value-level Consumer<T>. The author's intent, visible in the surrounding comment at lines 386-390, was a value transmute. The shipped code is one level of indirection off.
The resulting Consumer<T> has its internal Arc::ptr set to the address of the producer field on the Sender, not the real ArcInner<Buffer<T>>. Every subsequent consumer.try_pop() walks Buffer<T> fields at offsets that lie inside the Sender<T> struct (over send_new, inner) and adjacent memory, an out-of-bounds read. When the fake Consumer<T> is dropped at the end of the unsafe block, its Drop calls Arc::drop_in_place on a non-ArcInner address: it decrements bytes that the type system treats as strong_count: AtomicUsize but that are actually the real Arc::ptr value of the Sender, and at zero count it calls dealloc(Layout::for_value(...)) on an address the allocator never returned.
Reachable from 100% safe Rust through the canonical channel pattern: a tx.send(msg) that races with rx.drop(). This is consistent with the SIGSEGV that issue #3 reports in your own test suite.
Affected code (0.2.0, master at 23a9ce7)
```rust // src/lib.rs:384-401 DISCONNECTED => { self.inner.counter.store (DISCONNECTED, Ordering::SeqCst); // We want to guarantee if a message was not received that we get it // back; since spsc::{Producer,Consumer} have the same // internal representation (as a singleton struct containing Arc // >), we can safely transmute the producer in order to // pop the message back if it was orphaned. unsafe { let consumer : spsc::Consumer = std::mem::transmute (self.producer.get()); // <-- POINTER, not value let first = consumer.try_pop(); let second = consumer.try_pop(); assert!(second.is_none()); // <-- line 396; smoking-gun assert if let Some(t) = first { return Err (SendError (t)) } } }, self.producer is UnsafeCell> (line 29). UnsafeCell::::get(&self) returns mut X, a raw pointer, 8 bytes on 64-bit. The signature of transmute is transmute::(src: Src) -> Dst, so the call expands to transmute::<mut spsc::Producer, spsc::Consumer>(self.producer.get()). 8 bytes of pointer are reinterpreted as the bytes of a Consumer.
In bounded-spsc-queue-0.4.0, both Producer and Consumer are newtypes around Arc>, one pointer wide. The destination value therefore has Arc::ptr == &mut Producer as *const ArcInner>. To be a valid Arc>, that pointer must point to ArcInner { strong: AtomicUsize, weak: AtomicUsize, data: Buffer }, but it actually points to the start of Sender (the producer field). The first 8 bytes there hold the real Arc::ptr. The fake Arc reads those bytes as strong_count. The fake try_pop() then reads Buffer head/tail/data slots starting at offset 16 inside the Sender, that is, inside the send_new and inner fields.
The author's intent (per the comment at lines 386-390) was a value-level transmute:
let producer_val: spsc::Producer = std::ptr::read(self.producer.get()); let consumer : spsc::Consumer = std::mem::transmute(producer_val); which is layout-sound iff Producer and Consumer have identical layouts (they do, both are single-Arc newtypes). The shipped code is one indirection off.
Reachability The branch is not reachable single-threaded. Receiver::drop (line 332) stores connected = false before setting counter = DISCONNECTED; Sender::send (line 359) early-returns on connected == false. The trigger is a TOCTOU race:
Sender's self.inner.connected.load(SeqCst) reads true. Receiver-drop runs: stores connected = false and counter.compare_exchange(_, DISCONNECTED, SeqCst, SeqCst). Sender's self.inner.counter.fetch_add(1, SeqCst) (line 379) sees DISCONNECTED and enters the unsafe block. Under heavy contention this reproduces ~3/10 trials in release mode.
Proof of concept (race shape) // Cargo.toml: unbounded-spsc = "0.2" use std::thread; use unbounded_spsc::channel;
fn main() { for trial in 0..500 { let (tx, rx) = channel::>(); let started = std::sync::Arc::new( std::sync::atomic::AtomicBool::new(false)); let s = started.clone(); let h = thread::spawn(move || { s.store(true, std::sync::atomic::Ordering::SeqCst); for _ in 0..10_000 { let _ = tx.send(Box::new(0xDEAD_BEEF)); } }); while !started.load(std::sync::atomic::Ordering::SeqCst) { std::hint::spin_loop(); } drop(rx); let _ = h.join(); eprintln!("trial {trial} ok"); } } Observed:
Release-mode (no sanitizer): Segmentation fault (core dumped) reliably within a few trials. The non-segfaulting trials are masked by the separate send_new.send(new_consumer).unwrap() panic, see Secondary defect below. -Zsanitizer=address -Zbuild-std (nightly): ASan reports stack-buffer-overflow / stack-use-after-scope from the fake-Consumer's try_pop walking off the Sender frame. This matches the SIGSEGV reported in your own issue #3.
Smoking-gun upstream evidence src/lib.rs:975 in the project's test suite carries a TODO:
// TODO: failures // - failed with assertion on line 394 in send fn // assert!(second.is_none()) That is the assertion site of the transmute block (line 396 in 0.2.0 / master). You have observed try_pop() returning a non-None value where logically there should be none, which is exactly what reading random bytes from the Sender's send_new / inner fields produces, and the symptom has been marked as a flaky test rather than recognised as UB.
Impact Reachable from 100% safe Rust. Concrete UB primitives:
OOB read of bytes adjacent to the Sender struct via fake Consumer::try_pop(). The popped T is returned through Err(SendError(t)) to safe-code, an allocator-layout-controlled leak of process memory. OOB write via fake Arc::drop AtomicUsize::fetch_sub on bytes that are actually the real Arc::ptr value of the Sender. Allocator corruption via fake Arc::drop calling dealloc(Layout::for_value(...)) on a non-allocated address. The Sender struct holds the real Arc immediately after the producer field; the deallocator call therefore uses a layout the allocator never allocated, which on glibc is a confirmed double-free / arbitrary-bucket-poisoning primitive, and on hardened allocators (jemalloc-secure, mimalloc-secure) is an immediate abort. Secondary defect (same call path, bonus) Sender::send line 369:
self.send_new.send(new_consumer).unwrap(); When the Sender's message queue is full, a fresh bounded_spsc_queue::Channel is allocated and the new Consumer is shipped over an std::sync::mpsc side-channel to the Receiver. If the Receiver has already been dropped, receive_new is gone and this unwrap() panics. The panic surfaces in your own test suite, issue #2 (tests::port_gone_concurrent panicked at src/lib.rs:369) and the in-source TODO at lines 365-368 already note the question "Are we sure that this is safe to unwrap or should we handle the result explicitly ?".
The fix is to return Err(SendError(t)) instead of unwrapping, same shape as the channel-closed result the function already returns on the connected-false path. This is not a memory-safety defect, only a panic, but it lives on the same TX/RX-race code path and a single coordinated patch can address both. Filing it here so we cover the full call site in one cycle.
Suggested patch (primary defect) Replace the pointer-as-value transmute with a value-level read and a ManuallyDrop to suppress the alias's Producer::drop on subsequent exit:
unsafe { use core::mem::ManuallyDrop;
// Sound value-level transmute: Producer<T> and Consumer<T> are both
// newtypes around Arc<Buffer<T>>, so the value layouts match.
// ptr::read takes ownership of the Producer's bytes without running
// Producer's Drop.
let producer_val: spsc::Producer<T> = std::ptr::read(self.producer.get());
let consumer : spsc::Consumer<T> = std::mem::transmute(producer_val);
let first = consumer.try_pop();
let second = consumer.try_pop();
assert!(second.is_none());
if let Some(t) = first {
return Err(SendError(t));
}
// consumer drops here; the same memory backs `producer`, so suppress
// the double Producer drop:
let _ = ManuallyDrop::new(consumer);
} Cleaner: restructure Sender to hold producer and consumer in a private enum Endpoint so no transmute is required, or use the bounded_spsc_queue::Producer::reclaim() escape hatch if available.
Suggested patch (secondary defect) if let Err(std::sync::mpsc::SendError(_)) = self.send_new.send(new_consumer) { // Receiver has been dropped: take the message back as the public // SendError, the same way the connected==false early-return does. return Err(SendError(t)); } Regression test (release-mode, race shape)
[test]
fn race_disconnect_does_not_corrupt_sender_or_abort() { for _ in 0..200 { let (tx, rx) = unbounded_spsc::channel::>(); let h = std::thread::spawn(move || { for _ in 0..10_000 { let _ = tx.send(Box::new(0xDEAD_BEEF)); } }); drop(rx); h.join().unwrap(); } } Reverse dependencies Two crates on crates.io depend on unbounded-spsc, both owned by you: apis (process-calculus framework) and gooey-rs (tile-UI library, unbounded-spsc gated behind opengl/fmod features). The OpenGL/FMOD callback-mailbox use is a natural rx-drop-during-tx-send scenario at scene-graph teardown. A single coordinated bump cycle is feasible.
Researcher Berkant Koc me@berkoc.com PGP: 0C588DFD76204987284213EA0AC529C41F8AA5D6
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "unbounded-spsc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46690"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-415",
"CWE-704",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T19:05:21Z",
"nvd_published_at": "2026-06-12T16:16:29Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n`Sender::send` in `src/lib.rs` contains an `unsafe` block in the `DISCONNECTED` arm that transmutes a **raw pointer** (`*mut Producer\u003cT\u003e`) into the bytes of a **value-level** `Consumer\u003cT\u003e`. The author\u0027s intent, visible in the surrounding comment at lines 386-390, was a value transmute. The shipped code is one level of indirection off.\n\nThe resulting `Consumer\u003cT\u003e` has its internal `Arc::ptr` set to the address of the `producer` field on the `Sender`, not the real `ArcInner\u003cBuffer\u003cT\u003e\u003e`. Every subsequent `consumer.try_pop()` walks `Buffer\u003cT\u003e` fields at offsets that lie inside the `Sender\u003cT\u003e` struct (over `send_new`, `inner`) and adjacent memory, an out-of-bounds read. When the fake `Consumer\u003cT\u003e` is dropped at the end of the `unsafe` block, its `Drop` calls `Arc::drop_in_place` on a non-`ArcInner` address: it decrements bytes that the type system treats as `strong_count: AtomicUsize` but that are actually the real `Arc::ptr` value of the `Sender`, and at zero count it calls `dealloc(Layout::for_value(...))` on an address the allocator never returned.\n\nReachable from 100% safe Rust through the canonical channel pattern: a `tx.send(msg)` that races with `rx.drop()`. This is consistent with the SIGSEGV that issue #3 reports in your own test suite.\n\n## Affected code (0.2.0, master at `23a9ce7`)\n\n```rust\n// src/lib.rs:384-401\nDISCONNECTED =\u003e {\n self.inner.counter.store (DISCONNECTED, Ordering::SeqCst);\n // We want to guarantee if a message was not received that we get it\n // back; since spsc::{Producer,Consumer} have the same\n // internal representation (as a singleton struct containing Arc\n // \u003cBuffer \u003cT\u003e\u003e), we can safely transmute the producer in order to\n // pop the message back if it was orphaned.\n unsafe {\n let consumer : spsc::Consumer \u003cT\u003e\n = std::mem::transmute (self.producer.get()); // \u003c-- POINTER, not value\n let first = consumer.try_pop();\n let second = consumer.try_pop();\n assert!(second.is_none()); // \u003c-- line 396; smoking-gun assert\n if let Some(t) = first {\n return Err (SendError (t))\n }\n }\n},\nself.producer is UnsafeCell\u003cspsc::Producer\u003cT\u003e\u003e (line 29). UnsafeCell::\u003cX\u003e::get(\u0026self) returns *mut X, a raw pointer, 8 bytes on 64-bit. The signature of transmute is transmute::\u003cSrc, Dst\u003e(src: Src) -\u003e Dst, so the call expands to transmute::\u003c*mut spsc::Producer\u003cT\u003e, spsc::Consumer\u003cT\u003e\u003e(self.producer.get()). 8 bytes of pointer are reinterpreted as the bytes of a Consumer\u003cT\u003e.\n\nIn bounded-spsc-queue-0.4.0, both Producer\u003cT\u003e and Consumer\u003cT\u003e are newtypes around Arc\u003cBuffer\u003cT\u003e\u003e, one pointer wide. The destination value therefore has Arc::ptr == \u0026mut Producer\u003cT\u003e as *const ArcInner\u003cBuffer\u003cT\u003e\u003e. To be a valid Arc\u003cBuffer\u003cT\u003e\u003e, that pointer must point to ArcInner { strong: AtomicUsize, weak: AtomicUsize, data: Buffer\u003cT\u003e }, but it actually points to the start of Sender\u003cT\u003e (the producer field). The first 8 bytes there hold the real Arc::ptr. The fake Arc reads those bytes as strong_count. The fake try_pop() then reads Buffer\u003cT\u003e head/tail/data slots starting at offset 16 inside the Sender\u003cT\u003e, that is, inside the send_new and inner fields.\n\nThe author\u0027s intent (per the comment at lines 386-390) was a value-level transmute:\n\nlet producer_val: spsc::Producer\u003cT\u003e = std::ptr::read(self.producer.get());\nlet consumer : spsc::Consumer\u003cT\u003e = std::mem::transmute(producer_val);\nwhich is layout-sound iff Producer\u003cT\u003e and Consumer\u003cT\u003e have identical layouts (they do, both are single-Arc newtypes). The shipped code is one indirection off.\n\nReachability\nThe branch is not reachable single-threaded. Receiver::drop (line 332) stores connected = false before setting counter = DISCONNECTED; Sender::send (line 359) early-returns on connected == false. The trigger is a TOCTOU race:\n\nSender\u0027s self.inner.connected.load(SeqCst) reads true.\nReceiver-drop runs: stores connected = false and counter.compare_exchange(_, DISCONNECTED, SeqCst, SeqCst).\nSender\u0027s self.inner.counter.fetch_add(1, SeqCst) (line 379) sees DISCONNECTED and enters the unsafe block.\nUnder heavy contention this reproduces ~3/10 trials in release mode.\n\nProof of concept (race shape)\n// Cargo.toml: unbounded-spsc = \"0.2\"\nuse std::thread;\nuse unbounded_spsc::channel;\n\nfn main() {\n for trial in 0..500 {\n let (tx, rx) = channel::\u003cBox\u003cu64\u003e\u003e();\n let started = std::sync::Arc::new(\n std::sync::atomic::AtomicBool::new(false));\n let s = started.clone();\n let h = thread::spawn(move || {\n s.store(true, std::sync::atomic::Ordering::SeqCst);\n for _ in 0..10_000 {\n let _ = tx.send(Box::new(0xDEAD_BEEF));\n }\n });\n while !started.load(std::sync::atomic::Ordering::SeqCst) {\n std::hint::spin_loop();\n }\n drop(rx);\n let _ = h.join();\n eprintln!(\"trial {trial} ok\");\n }\n}\nObserved:\n\nRelease-mode (no sanitizer): Segmentation fault (core dumped) reliably within a few trials. The non-segfaulting trials are masked by the separate send_new.send(new_consumer).unwrap() panic, see Secondary defect below.\n-Zsanitizer=address -Zbuild-std (nightly): ASan reports stack-buffer-overflow / stack-use-after-scope from the fake-Consumer\u0027s try_pop walking off the Sender frame.\nThis matches the SIGSEGV reported in your own issue #3.\n\nSmoking-gun upstream evidence\nsrc/lib.rs:975 in the project\u0027s test suite carries a TODO:\n\n// TODO: failures\n// - failed with assertion on line 394 in send fn\n// assert!(second.is_none())\nThat is the assertion site of the transmute block (line 396 in 0.2.0 / master). You have observed try_pop() returning a non-None value where logically there should be none, which is exactly what reading random bytes from the Sender\u0027s send_new / inner fields produces, and the symptom has been marked as a flaky test rather than recognised as UB.\n\nImpact\nReachable from 100% safe Rust. Concrete UB primitives:\n\nOOB read of bytes adjacent to the Sender\u003cT\u003e struct via fake Consumer\u003cT\u003e::try_pop(). The popped T is returned through Err(SendError(t)) to safe-code, an allocator-layout-controlled leak of process memory.\nOOB write via fake Arc::drop AtomicUsize::fetch_sub on bytes that are actually the real Arc::ptr value of the Sender.\nAllocator corruption via fake Arc::drop calling dealloc(Layout::for_value(...)) on a non-allocated address. The Sender struct holds the real Arc\u003cInner\u003e immediately after the producer field; the deallocator call therefore uses a layout the allocator never allocated, which on glibc is a confirmed double-free / arbitrary-bucket-poisoning primitive, and on hardened allocators (jemalloc-secure, mimalloc-secure) is an immediate abort.\nSecondary defect (same call path, bonus)\nSender::send line 369:\n\nself.send_new.send(new_consumer).unwrap();\nWhen the Sender\u0027s message queue is full, a fresh bounded_spsc_queue::Channel is allocated and the new Consumer\u003cT\u003e is shipped over an std::sync::mpsc side-channel to the Receiver. If the Receiver has already been dropped, receive_new is gone and this unwrap() panics. The panic surfaces in your own test suite, issue #2 (tests::port_gone_concurrent panicked at src/lib.rs:369) and the in-source TODO at lines 365-368 already note the question \"Are we sure that this is safe to unwrap or should we handle the result explicitly ?\".\n\nThe fix is to return Err(SendError(t)) instead of unwrapping, same shape as the channel-closed result the function already returns on the connected-false path. This is not a memory-safety defect, only a panic, but it lives on the same TX/RX-race code path and a single coordinated patch can address both. Filing it here so we cover the full call site in one cycle.\n\nSuggested patch (primary defect)\nReplace the pointer-as-value transmute with a value-level read and a ManuallyDrop to suppress the alias\u0027s Producer::drop on subsequent exit:\n\nunsafe {\n use core::mem::ManuallyDrop;\n\n // Sound value-level transmute: Producer\u003cT\u003e and Consumer\u003cT\u003e are both\n // newtypes around Arc\u003cBuffer\u003cT\u003e\u003e, so the value layouts match.\n // ptr::read takes ownership of the Producer\u0027s bytes without running\n // Producer\u0027s Drop.\n let producer_val: spsc::Producer\u003cT\u003e = std::ptr::read(self.producer.get());\n let consumer : spsc::Consumer\u003cT\u003e = std::mem::transmute(producer_val);\n\n let first = consumer.try_pop();\n let second = consumer.try_pop();\n assert!(second.is_none());\n if let Some(t) = first {\n return Err(SendError(t));\n }\n\n // consumer drops here; the same memory backs `producer`, so suppress\n // the double Producer drop:\n let _ = ManuallyDrop::new(consumer);\n}\nCleaner: restructure Sender\u003cT\u003e to hold producer and consumer in a private enum Endpoint\u003cT\u003e so no transmute is required, or use the bounded_spsc_queue::Producer\u003cT\u003e::reclaim() escape hatch if available.\n\nSuggested patch (secondary defect)\nif let Err(std::sync::mpsc::SendError(_)) = self.send_new.send(new_consumer) {\n // Receiver has been dropped: take the message back as the public\n // SendError, the same way the connected==false early-return does.\n return Err(SendError(t));\n}\nRegression test (release-mode, race shape)\n#[test]\nfn race_disconnect_does_not_corrupt_sender_or_abort() {\n for _ in 0..200 {\n let (tx, rx) = unbounded_spsc::channel::\u003cBox\u003cu64\u003e\u003e();\n let h = std::thread::spawn(move || {\n for _ in 0..10_000 {\n let _ = tx.send(Box::new(0xDEAD_BEEF));\n }\n });\n drop(rx);\n h.join().unwrap();\n }\n}\nReverse dependencies\nTwo crates on crates.io depend on unbounded-spsc, both owned by you: apis (process-calculus framework) and gooey-rs (tile-UI library, unbounded-spsc gated behind opengl/fmod features). The OpenGL/FMOD callback-mailbox use is a natural rx-drop-during-tx-send scenario at scene-graph teardown. A single coordinated bump cycle is feasible.\n\nResearcher\nBerkant Koc me@berkoc.com\nPGP: 0C588DFD76204987284213EA0AC529C41F8AA5D6",
"id": "GHSA-6m57-8r3p-pqx6",
"modified": "2026-06-12T19:31:16Z",
"published": "2026-05-29T19:05:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/spearman/unbounded-spsc/security/advisories/GHSA-6m57-8r3p-pqx6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46690"
},
{
"type": "PACKAGE",
"url": "https://github.com/spearman/unbounded-spsc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "unbounded-spsc: Sender::send pointer-as-value transmute causes OOB read and fake-Arc drop under TX/RX race"
}
GHSA-6M5G-83W7-WQM5
Vulnerability from github – Published: 2025-10-10 09:30 – Updated: 2025-10-10 09:30Out-of-bounds write in fingerprint trustlet prior to SMR Oct-2025 Release 1 allows local privileged attackers to write out-of-bounds memory.
{
"affected": [],
"aliases": [
"CVE-2025-21044"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-10T07:15:38Z",
"severity": "MODERATE"
},
"details": "Out-of-bounds write in fingerprint trustlet prior to SMR Oct-2025 Release 1 allows local privileged attackers to write out-of-bounds memory.",
"id": "GHSA-6m5g-83w7-wqm5",
"modified": "2025-10-10T09:30:48Z",
"published": "2025-10-10T09:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21044"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2025\u0026month=10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6M5J-HMV8-95G6
Vulnerability from github – Published: 2021-12-23 00:01 – Updated: 2022-04-20 00:01A stack-based buffer overflow vulnerability exists in the CMA check_udp_crc function of Garrett Metal Detectors’ iC Module CMA Version 5.0. A specially-crafted packet can lead to a stack-based buffer overflow during a call to memcpy. An attacker can send a malicious packet to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2021-21901"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-22T19:15:00Z",
"severity": "HIGH"
},
"details": "A stack-based buffer overflow vulnerability exists in the CMA check_udp_crc function of Garrett Metal Detectors\u2019 iC Module CMA Version 5.0. A specially-crafted packet can lead to a stack-based buffer overflow during a call to memcpy. An attacker can send a malicious packet to trigger this vulnerability.",
"id": "GHSA-6m5j-hmv8-95g6",
"modified": "2022-04-20T00:01:59Z",
"published": "2021-12-23T00:01:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21901"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2021-1353"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6M5W-Q2GJ-4F48
Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2023-05-22 18:30Out of bound write vulnerability in subsystem for Intel(R) AMT before versions 11.8.65, 11.11.65, 11.22.65, 12.0.35 may allow an authenticated user to potentially enable escalation of privilege via adjacent network access.
{
"affected": [],
"aliases": [
"CVE-2019-0096"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-17T16:29:00Z",
"severity": "MODERATE"
},
"details": "Out of bound write vulnerability in subsystem for Intel(R) AMT before versions 11.8.65, 11.11.65, 11.22.65, 12.0.35 may allow an authenticated user to potentially enable escalation of privilege via adjacent network access.",
"id": "GHSA-6m5w-q2gj-4f48",
"modified": "2023-05-22T18:30:17Z",
"published": "2022-05-24T16:46:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0096"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K84591451"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00213.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-3
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.
- Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
Mitigation MIT-4.1
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.
Mitigation MIT-10
Strategy: Environment Hardening
- Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.
- D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.
Mitigation MIT-9
- Consider adhering to the following rules when allocating and managing an application's memory:
- Double check that the buffer is as large as specified.
- When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.
- Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.
- If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.
Mitigation MIT-11
Strategy: Environment Hardening
- Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.
- Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.
- For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].
Mitigation MIT-12
Strategy: Environment Hardening
- Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.
- For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].
Mitigation MIT-13
Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.
No CAPEC attack patterns related to this CWE.