https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 04 Nov 2026 23:17:59 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-116775 <p>pageant provides a PageantStream type that implements AsyncRead and AsyncWrite traits and can be used to communicate with a running Pageant instance. From 0.2.0 until 0.2.5, PageantStream::new in pageant/src/wmmessage.rs trusts a peer-controlled four-byte length prefix and buffers until len + 4 bytes are available without checking the fixed _AGENT_MAX_MSGLEN transport capacity. An application that bridges an SSH forwarded-agent channel to the raw stream can allow a malicious server to force large allocations or retain a partially filled frame, causing client memory exhaustion. This issue is fixed in version 0.2.5.</p> <p>pageant provides a PageantStream type that implements AsyncRead and AsyncWrite traits and can be used to communicate with a running Pageant instance. From 0.2.0 until 0.2.5, PageantStream::new in pageant/src/wmmessage.rs trusts a peer-controlled four-byte length prefix and buffers until len + 4 bytes are available without checking the fixed _AGENT_MAX_MSGLEN transport capacity. An application that bridges an SSH forwarded-agent channel to the raw stream can allow a malicious server to force large allocations or retain a partially filled frame, causing client memory exhaustion. This issue is fixed in version 0.2.5.</p> https://db.gcve.eu/vuln/fkie_cve-2026-116775 https://db.gcve.eu/vuln/ghsa-662x-8wvj-2276 <p><strong>Affected:</strong> crates.io: pageant</p> <p>## Summary</p> <p>`pageant::PageantStream` reads a 4-byte big-endian length prefix from its input stream and buffers until `len + 4` bytes are available, without ever validating `len`. The underlying WM_COPYDATA transport physically cannot carry frames larger than 8 KiB (`_AGENT_MAX_MSGLEN`, the fixed-size shared memory mapping), so an oversized frame is destined to fail — but only after the re-framing task has already buffered the full claimed size. A peer controlling the stream bytes can claim a frame of up to ~4 GiB and either stream that much data (forcing a corresponding allocation) or simply stop mid-frame and keep the partial buffer resident indefinitely.</p> <p>## Vulnerable code</p> <p>`pageant/src/wmmessage.rs`, `PageantStream::new()` (the spawned re-framing task), current main:</p> <p>```rust let mut buf = BytesMut::new(); while let Ok(n) = two.read_buf(&amp;mut buf).await { if n == 0 { break; } if buf.len() &lt; 4 { continue; } let len = BigEndian::read_u32(&amp;buf) as usize; if buf.len() &lt; len + 4 { continue; } // &lt;-- `len` is trusted; no upper bound let msg = buf.split_to(len + 4).freeze(); // ... } ```</p> <p>`len` is consumed verbatim from the stream, so `buf` grows towards `len + 4`. Even a &#34;complete&#34; oversized frame cannot succeed: `query_pageant_direct()` writes `msg` into the `_AGENT_MAX_MSGLEN`-sized (8192 bytes) shared mapping and fails with `Error::Overflow` for anything larger — the unbounded buffering is therefore pure attacker-controlled memory growth.</p> <p>History:…</p> <p><strong>Affected:</strong> crates.io: pageant</p> <p>## Summary</p> <p>`pageant::PageantStream` reads a 4-byte big-endian length prefix from its input stream and buffers until `len + 4` bytes are available, without ever validating `len`. The underlying WM_COPYDATA transport physically cannot carry frames larger than 8 KiB (`_AGENT_MAX_MSGLEN`, the fixed-size shared memory mapping), so an oversized frame is destined to fail — but only after the re-framing task has already buffered the full claimed size. A peer controlling the stream bytes can claim a frame of up to ~4 GiB and either stream that much data (forcing a corresponding allocation) or simply stop mid-frame and keep the partial buffer resident indefinitely.</p> <p>## Vulnerable code</p> <p>`pageant/src/wmmessage.rs`, `PageantStream::new()` (the spawned re-framing task), current main:</p> <p>```rust let mut buf = BytesMut::new(); while let Ok(n) = two.read_buf(&amp;mut buf).await { if n == 0 { break; } if buf.len() &lt; 4 { continue; } let len = BigEndian::read_u32(&amp;buf) as usize; if buf.len() &lt; len + 4 { continue; } // &lt;-- `len` is trusted; no upper bound let msg = buf.split_to(len + 4).freeze(); // ... } ```</p> <p>`len` is consumed verbatim from the stream, so `buf` grows towards `len + 4`. Even a &#34;complete&#34; oversized frame cannot succeed: `query_pageant_direct()` writes `msg` into the `_AGENT_MAX_MSGLEN`-sized (8192 bytes) shared mapping and fails with `Error::Overflow` for anything larger — the unbounded buffering is therefore pure attacker-controlled memory growth.</p> <p>History:…</p> https://db.gcve.eu/vuln/ghsa-662x-8wvj-2276