Unbounded memory allocation in thrift binary protocol read_bytes

fn read_bytes(&mut self) -> crate::Result<Vec<u8>> {
    let num_bytes = self.transport.read_i32::<BigEndian>()? as usize; // length from the wire
    let mut buf = vec![0u8; num_bytes];                               // unbounded eager allocation
    self.transport.read_exact(&mut buf).map(|_| buf).map_err(From::from)
}

There is no check that num_bytes is non-negative or that it fits within the data actually available:

• ■A length of 0x7FFFFFFF forces a ~2 GiB allocation; 0x20000000 forces 512 MiB; and so on, from only a 4-byte input.
• ■A negative length casts to a huge usize (up to usize::MAX), causing an immediate allocation failure / abort.

read_string routes through read_bytes, so string fields are affected the same way. The sink is reachable from any peer sending binary-protocol data, so this is an unauthenticated, network-reachable denial of service.

The fix

From thrift 0.23.0 onward, read_bytes goes through read_binary_len, which rejects negative sizes and enforces (default 100 MiB), alongside default message, frame, and recursion limits.