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 logic error in media/audio/pulse/pulse_util.cc results in a redundant call to pa_operation_unref, causing a potential double-free or use-after-free of PulseAudio operation objects. This occurs within the Audio Service process, which on Linux is currently unsandboxed by default. The vulnerability is potentially reachable through the getDisplayMedia API when specific audio loopback features are enabled.

Affected files:

• media/audio/pulse/pulse_util.cc
• media/audio/pulse/pulse_loopback.cc
• media/audio/pulse/pulse_loopback_manager.cc
• media/audio/pulse/audio_manager_pulse.cc

Estimated timestamp from git blame: 2024-09-04

Vulnerability Details

A potential memory safety vulnerability exists in the PulseAudio utility implementation within the Chrome audio stack on Linux. The issue is a double-unref (which leads to a double-free) of pa_operation objects in media/audio/pulse/pulse_util.cc.

The helper function WaitForOperationCompletion is designed to wait for a PulseAudio operation to finish and then release the caller’s reference. As seen in media/audio/pulse/pulse_util.cc:

390: bool WaitForOperationCompletion(pa_threaded_mainloop* mainloop,
391:                                 pa_operation* operation,
...
425:   pa_operation_unref(operation);
426:   return true;
427: }

However, two functions added for PulseAudio system-loopback support incorrectly call pa_operation_unref a second time after WaitForOperationCompletion returns, despite the reference already being consumed:

1. MuteAllSinksExcept (lines 679-682):

   679:   WaitForOperationCompletion(mainloop, op, context);
   680:   // Clean up the operation after completion
   681:   if (op) {
   682:     pa_operation_unref(op);
   683:   }
   

2. UnmuteAllSinks (lines 718-721):

   718:   WaitForOperationCompletion(mainloop, op, context);
   719:   // Wait for the operation to complete to ensure all sinks are unmuted.
   720:   if (op) {
   721:     pa_operation_unref(op);
   722:   }
   

Since WaitForOperationCompletion already calls pa_operation_unref on the provided pointer, the subsequent call in the parent function results in a double-free of the pa_operation object. This can lead to heap corruption within the PulseAudio library or the process’s allocator.

Impact and Reachability

On Linux, the Audio Service typically runs as a separate utility process where the sandbox is disabled by default (the kAudioServiceSandbox feature is base::FEATURE_DISABLED_BY_DEFAULT for Linux in content/public/common/content_features.cc). Memory corruption in this process could lead to arbitrary code execution with the privileges of the user running Chromium.

This code path is reachable when the kPulseaudioLoopbackForScreenShare feature flag is enabled. An attacker could potentially trigger this by invoking the getDisplayMedia API with the suppressLocalAudioPlayback: true constraint. This configuration routes the request through AudioManagerPulse and PulseLoopbackManager, eventually calling the vulnerable functions in pulse_util.cc.

Potential Trigger Steps

Note: These steps are based on code analysis; our tooling cannot yet execute code to verify a proof-of-concept.

1. The user must have the experimental flag enabled (e.g., via chrome://flags/#pulseaudio-loopback-for-screen-share).
2. An attacker-controlled page calls navigator.mediaDevices.getDisplayMedia({ audio: { suppressLocalAudioPlayback: true } }).
3. The user is prompted to share their screen and accepts.
4. This triggers MuteAllSinksExcept in the Audio Service, causing the potential double-free of the PulseAudio operation object.
5. Closing the shared stream triggers UnmuteAllSinks, causing a second potential double-free.

Suggested Fix

Remove the redundant calls to pa_operation_unref(op) in MuteAllSinksExcept and UnmuteAllSinks (lines 682 and 721 in media/audio/pulse/pulse_util.cc). The WaitForOperationCompletion helper already correctly handles the reference release.

Additionally, MuteAllSinksExcept should be updated to properly unref the operation returned by pa_context_set_sink_mute_by_index (lines 671-673) to prevent a memory leak, similar to the corrected logic seen in other parts of the PulseAudio utility.

Evaluated with Chrome root at commit: 29093e11cf509e3593f6229e4b1b075cca356049

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.