IOBuf Integer Overflow Causes Heap Out-of-Bounds Write in Facebook folly and HHVM

Passing an attacker controlled size when creating an IOBuf could cause integer overflow, leading to an out of bounds write on the heap with the possibility of remote code execution. This issue affects versions of folly prior to v2021.07.22.00. This issue affects HHVM versions prior to 4.80.5, all versions between 4.81.0 and 4.102.1, all versions between 4.103.0 and 4.113.0, and versions 4.114.0, 4.115.0, 4.116.0, 4.117.0 and 4.118.1.

• Facebook folly: Versions before v2021.07.22.00 are affected. The identified fix is v2021.07.22.00.
• Facebook HHVM: Versions before 4.80.5 are affected; this branch is fixed in 4.80.5.
• Facebook HHVM: All versions from 4.81.0 through 4.102.1 are affected; the fix for this branch is 4.102.2.
• Facebook HHVM: All versions from 4.103.0 through 4.113.0 are affected; the fix for this branch is 4.113.1.
• Facebook HHVM: 4.114.0, 4.115.0, 4.116.0, and 4.117.0 are affected; the corresponding fixes are 4.114.1, 4.115.1, 4.116.1, and 4.117.1.
• Facebook HHVM: 4.118.0 and 4.118.1 are affected; the fix for this branch is 4.118.2.

The status of HHVM branches not listed in the record is not established here.

The flaw is in size handling during creation of an IOBuf object, where an attacker-controlled size can cause an integer overflow. The resulting incorrect size calculation can lead to a write outside the intended heap object, matching CWE-122. The attacker-controlled input is the size passed into the IOBuf creation path. The normalized attack characteristics indicate network reachability without authentication or user interaction and with low complexity, but the available evidence does not identify the exact protocol, endpoint, or calling function. In HHVM, the vulnerable code is in Folly's IOBuf class; the specific request path that supplies the size remains unknown.

• Reachability: The flaw can be reached over the network when an attacker can cause creation of an IOBuf using an attacker-controlled size.
• Authentication and interaction: The normalized attack characteristics require neither authentication nor user interaction.
• Complexity: Complexity is characterized as low, although the exact conditions for reaching the vulnerable IOBuf creation path depend on how Folly or HHVM is used.
• Known status: The supplied evidence does not establish exploitation in the wild, a public exploit, or ransomware use. This is an evidence limitation, not a claim that such activity does not exist.

A heap out-of-bounds write can corrupt memory-management data, crash the process, or alter data in the service's address space. The record identifies possible remote code execution; if achieved, an attacker could execute code with the privileges of the HHVM process or application using Folly. The technical consequences may include loss of confidentiality, integrity, and availability within the vulnerable process's security authority. Actual impact depends on whether the attacker can reach the IOBuf creation path with controlled data and control the memory corruption sufficiently; the available evidence does not provide reliable exploit steps.

• HHVM services or applications integrating Folly may crash, interrupting request processing or reducing service availability.
• If the memory corruption is successfully turned into code execution, an attacker could execute code with the privileges of the HHVM process or consuming service.
• That execution could enable unauthorized data access, data modification, or compromise of other resources available to the process.
• The supplied evidence does not identify a specific victim or breach; actual impact depends on whether the deployment exposes a vulnerable IOBuf creation path to network-controlled data.

1. Upgrade Folly to v2021.07.22.00 or another vendor-confirmed fixed release, then rebuild and redeploy applications that vendor or bundle Folly.
2. For HHVM, upgrade within the affected branch: 4.80.5 for versions before 4.80.5; 4.102.2 for the branch from 4.81.0 through 4.102.1; 4.113.1 for the branch from 4.103.0 through 4.113.0; and 4.114.1, 4.115.1, 4.116.1, 4.117.1, or 4.118.2 for the corresponding affected releases.
3. For Debian 10 Buster and Ubuntu 18.04 Bionic, the HHVM advisory also identifies 4.80.6 and 4.102.3 as releases containing the security update and build-system compatibility changes.
4. Verify post-upgrade artifacts to ensure the running process uses the fixed Folly or HHVM code, rather than an older copy remaining in an image, bundle, or build cache.
5. The supplied evidence does not document an official workaround. Temporary restrictions on untrusted requests may reduce exposure, but they should not be treated as a vendor-confirmed fix.

1. Inventory HHVM servers and every Folly copy that is vendored, bundled, or statically compiled into an application.
2. Reconcile runtime versions, package metadata, manifests, and build artifacts to identify the release branch actually deployed.
3. Review network-facing request paths that can pass user-controlled sizes into IOBuf creation; the available evidence does not name a specific endpoint.
4. Review process restart logs, crash dumps, and memory-corruption diagnostics following anomalous requests as precautionary indicators. No specific IOC or log signature is established, and the absence of such evidence does not prove that a system is safe.