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: The Chromecast mixer service potentially listens on an unauthenticated abstract-namespace UNIX domain socket. An attacker with a local foothold could supply stream parameters that trigger an integer overflow during buffer pool allocation. This could result in an undersized buffer allocation and subsequent controlled heap out-of-bounds write in the browser process.

Affected files:

• chromecast/media/audio/net/audio_socket_service_uds.cc

Estimated timestamp from git blame: 2019-11-15

Description

A potential integer overflow and narrowing vulnerability exists in the Chromecast MixerInputConnection::CreateBufferPool function. When MIXER_IN_CAST_SHELL is enabled, the mixer service runs inside the privileged cast_shell browser process and listens on an abstract-namespace UNIX domain socket (/tmp/mixer-service) with an authentication callback that may unconditionally accept incoming connections.

An attacker with a local foothold (e.g., from a compromised sandboxed process such as a utility or GPU process, or another local daemon) could connect to this abstract socket and send a malicious kMetadata message containing custom output_stream_params parameters.

In the MixerInputConnection constructor, params.fill_size_frames() is parsed without clamping and passed to CreateBufferPool(int frame_count):

void MixerInputConnection::CreateBufferPool(int frame_count) {
  DCHECK_GT(frame_count, 0);
  buffer_pool_frames_ = frame_count;
  int converted_buffer_size =
      kAudioMessageHeaderSize + num_channels_ * sizeof(float) * frame_count;
  buffer_pool_ = base::MakeRefCounted<IOBufferPool>(converted_buffer_size, ...);
  ...
}

If the attacker controls num_channels_ (e.g., 2) and provides a large frame_count (e.g., 0x20000001 or 536870913), the multiplication in size_t (on 64-bit platforms) evaluates to:

$$2 \times 4 \times 536870913 = 4294967304 \text{ (0x100000008)}$$

Adding kAudioMessageHeaderSize (16 bytes) results in 4294967320 (0x100000018). When this value is implicitly narrowed and stored into the 32-bit signed integer converted_buffer_size, it truncates to 24 bytes.

An IOBufferPool is then created with a size of only 24 bytes, while the capacity state buffer_pool_frames_ retains the large original value 536870913. When the attacker subsequently sends a kAudio message containing valid audio data (e.g., 100 frames), the size checks against buffer_pool_frames_ pass, and ConvertInterleavedData writes the converted floats directly into the undersized 24-byte heap buffer, leading to a controlled linear out-of-bounds write.

Note: Our tooling does not currently have the capability to run code, and parts of the CMA backend mixer implementation are not present in the public repository, so these findings are based on static analysis of the public interfaces and reference files.

Potential Attack Steps

1. Establish a socket connection to the abstract address \0/tmp/mixer-service from a process with local network capabilities.
2. Send a structured kMetadata message with num_channels = 2 and fill_size_frames = 536870913.
3. Send a follow-up kAudio message with a moderate number of frames (e.g., 100 frames of INT16 PCM data).
4. This would cause the receiver to allocate a 24-byte buffer and write 800 bytes of converted float data into it, corrupting adjacent heap objects in the cast_shell browser process.

Suggested Fix

To prevent this vulnerability, enforce strict clamping and bounds validation on all incoming stream parameters in the MixerInputConnection constructor and use safe arithmetic (such as base::CheckedNumeric) when calculating buffer sizes:

base::CheckedNumeric<int> safe_buffer_size = kAudioMessageHeaderSize;
safe_buffer_size += base::CheckedNumeric<int>(num_channels_)
                  * sizeof(float)
                  * frame_count;

if (!safe_buffer_size.IsValid()) {
  // Handle error, reject connection
}
int converted_buffer_size = safe_buffer_size.ValueOrDie();

Evaluated with Chrome root at commit: d8b226a3be7c9c1ac9240c09e14698866c82e4ac

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.