Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A 32-bit integer overflow in Huffman size calculation can lead to an undersized heap allocation. This results in a potential linear heap out-of-bounds write in the browser process on 32-bit Android devices when processing large HTTP headers.

Affected files:

• net/third_party/quiche/src/quiche/http2/hpack/huffman/hpack_huffman_encoder.cc
• net/third_party/quiche/src/quiche/http2/hpack/hpack_encoder.cc
• net/third_party/quiche/src/quiche/quic/core/qpack/qpack_instruction_encoder.cc

Estimated timestamp from git blame: 2020-10-04

Summary

On 32-bit platforms, a potential integer overflow in http2::HuffmanSize() can lead to a heap out-of-bounds (OOB) write in http2::HuffmanEncode(). This issue arises when calculating the total bit length of a large input string during HPACK or QPACK encoding. On Android, where the Network Service typically runs within the browser process, this could potentially be exploited by a compromised renderer to achieve a sandbox escape.

Root Cause Analysis

The issue is located in net/third_party/quiche/src/quiche/http2/hpack/huffman/hpack_huffman_encoder.cc. The function HuffmanSize calculates the total number of bits required for encoding:

size_t HuffmanSize(absl::string_view plain) {
  size_t bits = 0;
  for (const uint8_t c : plain) {
    bits += HuffmanSpecTables::kCodeLengths[c];
  }
  return (bits + 7) / 8;
}

On 32-bit systems, size_t is 32 bits. The maximum Huffman code length is 30 bits. An input string of approximately 143 million bytes (e.g., repeating a byte with a 30-bit code) will cause the bits counter to overflow. For instance, 143,165,577 iterations of a 30-bit code length results in a total of 4,294,967,310 bits, which overflows a 32-bit integer to the value 14. The function then returns an incorrectly small size (e.g., 2 bytes).

Subsequently, HuffmanEncode uses this overflowed size to allocate the output buffer:

void HuffmanEncode(absl::string_view input, size_t encoded_size,
                   std::string* output) {
  const size_t original_size = output->size();
  const size_t final_size = original_size + encoded_size;
  output->resize(final_size + 4, 0);
  // ...
  size_t bit_counter = 0;
  for (uint8_t c : input) {
    char* const current = first + (bit_counter / 8);
    bit_counter += HuffmanSpecTables::kCodeLengths[c];
    *current |= code >> 32;
    // ... potential OOB writes occur here
  }
}

Because encoded_size is incorrectly small, output->resize creates an undersized buffer. However, the encoding loop continues to process the full input string, using bit_counter to calculate write offsets, leading to a potential linear heap OOB write.

Potential Attack Vector

A compromised renderer process could potentially trigger this by sending a very large HTTP header (e.g., ~140 MiB) via the network.mojom.URLLoaderFactory Mojo interface. On 32-bit Android, the Network Service runs in the browser process by default, meaning this corruption would occur in a high-privilege context.

Suggested Fix

1. Modify HuffmanSize and HuffmanEncode to use 64-bit integers (uint64_t) for bit counters to prevent overflows on 32-bit platforms.
2. Add explicit checks in HuffmanSize to handle cases where the calculated size would exceed platform limits.
3. Ensure that HuffmanEncode verifies the consistency of the provided encoded_size with a check that remains active in release builds.

Evaluated with Chrome root at commit: 1a8d40fc44df2088d5945c0bf53584038aa1614a

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.