CVE-2019-3553

A malicious client sends a Thrift message that declares a container (list, set, map) or string with a size field that is much larger than the actual payload bytes that follow. The server trusts the declared size and attempts to allocate memory for the full container before reading the elements. Because the declared size can be arbitrarily large while the actual message is short, the server may allocate an enormous buffer, leading to memory exhaustion and denial of service. No authentication is required; the attacker only needs network access to a vulnerable Thrift endpoint.

The vulnerability exists in the container-reading logic of Facebook Thrift's protocol layer. The patch adds `canReadNElements()` checks in `protocol_methods` for `list`, `set`, and `map` types (ref_id=1), and adds `in_.canAdvance(size)` checks in `BinaryProtocolReader::readStringBody` and `CompactProtocolReader::readStringBody` for string fields (ref_id=2). A new `throwTruncatedData()` static method on `TProtocolException` is introduced to signal the error.

The fix adds a lightweight lower-bound check — `canReadNElements()` — before reading list, set, and map elements (ref_id=1). This function verifies that the remaining buffer contains at least `n * sizeof(element_type)` bytes. If the check fails, `throwTruncatedData()` is called, which raises a `TProtocolException` with the message "Not enough bytes to read the entire message, the data appears to be truncated". Similarly, string readers in both `BinaryProtocolReader` and `CompactProtocolReader` now call `in_.canAdvance(size)` before reserving memory (ref_id=2). These checks prevent the server from committing to a large allocation when the payload is demonstrably too short.