Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
`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. Vulnerable code `pageant/src/wmmessage.rs`, `PageantStream::new()` (the spawned re-framing task), current main: ```rust let mut buf = BytesMut::new(); while let Ok(n) = two.read_buf(&mut buf).await { if n == 0 { break; } if buf.len() Result > { let mut stream = pageant::PageantStream::new().await?; // Claim a ~4 GiB frame, stream…
Recommended action: Upgrade to 0.2.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MemoryMap::read in the pageant crate (part of the russh workspace, used by russh's SSH-agent client on Windows via AgentClient::connectpageant) copies a peer-controlled number of bytes out of an 8192-byte shared-memory view with no bounds check — unlike the sibling MemoryMap::write, which correctly rejects oversize access with Error::Overflow. The byte count comes straight from a u32 length prefix that the responding "Pageant" process writes into the shared mapping. A malicious local process that answers as the Pageant agent can therefore cause: - an out-of-bounds read past the 8 KiB view (access violation → process crash; or disclosure of adjacent process memory if the following page is committed) - an allocation of up to ~4 GiB from a single u32 (vec![0; n]). This was reproduced end-to-end against the real, unmodified pageant crate (not a model) on x8664-pc-windows-gnu under Wine; see "Proof of concept". Impact - Availability / DoS (reliable). MemoryMap::read(size) walks…
Recommended action: Upgrade to 0.2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.