Advisories for Cargo/Zebra-Network package

The P2P codec's Codec::decode() method calls src.reserve(body_len + HEADER_LEN) after parsing a 24-byte protocol header, using the attacker-claimed body_len field. This reserves up to MAX_PROTOCOL_MESSAGE_LEN (~2 MiB) of virtual buffer capacity per connection before any body bytes arrive and before the handshake completes. However, BytesMut::reserve() sets virtual capacity without committing physical memory pages. The operating system does not allocate physical RAM until bytes are actually written into the buffer. Since …

An address normalization mismatch between the handshake path and the mempool misbehavior path causes a deterministic assertion panic when a peer connects via IPv4 to a dual-stack IPv6 listener and then triggers a mempool misbehavior penalty. The handshake path canonicalizes IPv4-mapped IPv6 addresses to plain IPv4 when storing the peer in the address book via MetaAddr::new_connected. The mempool misbehavior path forwards the raw transient socket address (IPv4-mapped IPv6 form) when …

Several inbound deserialization paths in Zebra allocated buffers sized against generic transport or block-size ceilings before the tighter protocol or consensus limits were enforced. An unauthenticated or post-handshake peer could therefore force the node to preallocate and parse for orders of magnitude more data than the protocol intended, across headers messages, equihash solutions in block headers, Sapling spend vectors in V5/V4 transactions, and coinbase script bytes in blocks.

When deserializing addr or addrv2 messages, which contain vectors of addresses, Zebra would fully deserialize them up to a maximum length (over 233,000) that was derived from the 2 MiB message size limit. This is much larger than the actual limit of 1,000 messages from the specification. Zebra would eventually check that limit but, at that point, the memory for the larger vector was already allocated. An attacker could cause …