2059164 - Uninitialized heap memory disclosed to web content via uint32 truncation in AudioSegment::Resample (media element captured into Web Audio)

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Tom Ritter [:tjr]]

AudioSegment::Resample (dom/media/AudioSegment.cpp) computes the resampler output size in 64 bits but assigns it to a uint32_t: outSize = ((uint64_t)c.mDuration * aOutRate + aInRate - 1) / aInRate. When a media file declares a very low sample rate (a FLAC STREAMINFO rate of 1 Hz is accepted) and the MediaTrackGraph rate is attacker-chosen via AudioContext({sampleRate}) (allowed range 3000-768000, dom/media/webaudio/WebAudioUtils.h:34-35), the product overflows 32 bits and outSize is truncated. Additionally, the speex in/out variable inFrames (line 65) is declared outside the per-channel loop: when the truncated output buffer limits channel 0's resampling, speex reports fewer (here zero) input frames consumed, and all later channels are resampled with that reduced input count, producing fewer output frames than channel 0. Each channel buffer is allocated with AppendElements(outSize), which leaves float elements uninitialized, and SetLength(outFrames) shrinks the length without clearing or freeing the allocation; c.mDuration is then set to channel 0's length (line 84). Downstream consumers read c.mDuration frames from every channel pointer, so the never-written tail of later channels — raw uninitialized heap — is delivered as audio samples that content JS reads back through a ScriptProcessorNode. All reads stay inside live allocations, so ASAN cannot flag them and no crash variant exists; the evidence is the proof strings captured from the content process. On the unmodified ASAN build, all 16384 leaked channel-1 samples read by page JS were 0xE4E4E4E4, Firefox's ASAN malloc_fill_byte=228 (build/sanitizers/AsanOptions.cpp:73-74) marking never-initialized malloc memory. With a one-line patch setting the ASAN-only malloc/free fill sizes to 0 (emulating release mozjemalloc, which does not junk-fill fresh allocations and poisons only the first 256 bytes of a free — memory/build/Globals.h), page JS recovered a heap-sprayed sentinel 0x4D5EC0DE in all 16384 leaked samples, i.e. the contents of previously freed heap allocations of an attacker-chosen size class. The leak is deterministic (size and location controlled by the FLAC blocksize and AudioContext rate) and repeatable per media element/context.

Build Info

• Branch: main
• Revision: ca6e9493686b3e5ed1cddb8d3a3974068463df71
• Timestamp: 2026-07-29T00:55:15+00:00

Affected Code

File: dom/media/AudioSegment.cpp, line 65-88

uint32_t inFrames = c.mDuration;            // shared across channels; speex in/out param
// Round up to allocate; the last frame may not be used.
NS_ASSERTION((UINT64_MAX - aInRate + 1) / c.mDuration >= aOutRate, "Dropping samples");
uint32_t outSize =
    (static_cast<uint64_t>(c.mDuration) * aOutRate + aInRate - 1) / aInRate;  // 64-bit value TRUNCATED to uint32
for (uint32_t i = 0; i < channels; i++) {
  T* out = output[i].AppendElements(outSize);  // floats left uninitialized
  uint32_t outFrames = outSize;
  const T* in = static_cast<const T*>(c.mChannelData[i]);
  dom::WebAudioUtils::SpeexResamplerProcess(aResampler.get(), i, in,
                                            &inFrames, out, &outFrames);  // inFrames updated to frames consumed by ch0
  MOZ_ASSERT(inFrames == c.mDuration);         // debug-only; not true when output buffer limits
  bufferPtrs[i] = out;
  output[i].SetLength(outFrames);              // shrink keeps allocation; ch1 length becomes 0
}
MOZ_ASSERT(channels > 0);
c.mDuration = output[0].Length();              // 16384, taken from channel 0
c.mBuffer = new mozilla::SharedChannelArrayBuffer<T>(std::move(output));
for (uint32_t i = 0; i < channels; i++) {
  c.mChannelData[i] = bufferPtrs[i];           // ch1 points at 16384 uninitialized floats
}

File: dom/media/mediasink/AudioDecoderInputTrack.cpp, line 78-81

if (mInputSampleRate != Graph()->GraphRate()) {
  aSegment.ResampleChunks(mResampler, &mResamplerChannelCount,
                          mInputSampleRate, Graph()->GraphRate());
}

The resample path is reached when an <audio> element is captured into Web Audio via AudioContext.createMediaElementSource: mInputSampleRate is the decoded file's declared rate (1 Hz from the FLAC STREAMINFO) and GraphRate() is the AudioContext sampleRate (attacker-chosen 262145). With chunk duration 16384 (one FLAC frame of blocksize 16384), outSize = ceil(16384*262145/1) = 4294983680 = 2^32 + 16384, truncated to 16384. Channel 0 fills its 16384-frame buffer while consuming 0 input frames, so inFrames becomes 0; channel 1 is then resampled from 0 input frames and produces 0 frames, leaving its entire 16384-float allocation uninitialized while c.mDuration says 16384.

Exploit Chain

1. Serve a 58-byte FLAC declaring sample rate 1 Hz, stereo, one frame with blocksize 16384 (two CONSTANT subframes), and create an AudioContext with sampleRate 262145.
2. Optionally groom the heap: allocate and free ~6600 ArrayBuffers of 65544 bytes filled with a chosen pattern (matches the 4*16384-byte channel-buffer size class), then GC.
3. Play the FLAC in an <audio> element captured via createMediaElementSource; AudioDecoderInputTrack::ConvertAudioDataToSegment calls AudioSegment::ResampleChunks with aInRate=1, aOutRate=262145.
4. outSize (2^32+16384) truncates to 16384; channel 0 produces 16384 frames consuming 0 input frames; channel 1 is resampled with inFrames=0 and produces 0 frames, so its 16384-float allocation is never written; c.mDuration is set to 16384.
5. Downstream mixing delivers 16384 frames per channel to a ScriptProcessorNode; page JS reinterprets channel 1's Float32 samples as uint32 bit patterns, reading raw uninitialized/recycled heap memory (observed: 0xE4E4E4E4 ASAN malloc fill on the pristine build; the sprayed 0x4D5EC0DE sentinel with release-allocator-emulating fill settings).
6. Repeat with new elements/contexts to read further heap chunks; up to (outSize - written) * 4 bytes leak per extra channel (FLAC supports up to 8 channels).

Steps to Reproduce

1. Build Firefox with /app/mozconfigs/mozconfig.linux.asan.fuzzing.
2. Run testcase.html under browser_evaluator with prefs {"fuzzing.enabled": true, "browser.dom.window.dump.enabled": true, "media.autoplay.default": 0, "media.autoplay.blocking_policy": 0, "media.cubeb.force_mock_context": true} (autoplay prefs stand in for a user gesture; the mock cubeb backend is needed because the host has no audio device).
3. Run A (no source changes): within ~10 s stderr shows 'POCLOG summary-10s frames=... ch0nz=16384 ch1nz=16384 sentinel=0 asanfill=0 other=16384 patterns=e4e4e4e4x16384' and 'POCLOG POC-LEAK: junk in channel 1' — all leaked samples are ASAN's malloc_fill_byte 0xE4 (never-written malloc memory).
4. Run B: git apply source_patch.diff (sets max_malloc_fill_size=0/max_free_fill_size=0 in the ASAN-build-only __asan_default_options to emulate release mozjemalloc fill behavior), rebuild, rerun: stderr shows 'sentinel=16384' and 'POCLOG POC-CONFIRMED: 4d5ec0de sprayed-heap sentinel recovered from resampled audio channel 1, count=16384'.
5. Deterministic truncation signature in both runs: exactly 16384 nonzero channel-0 frames ((16384*262145) mod 2^32) and media currentTime frozen at 16384/262145 ≈ 0.062 s.

Security Impact

• Severity: High
• Attacker capability: Web content JS deterministically reads uninitialized/recycled content-process heap memory: per iteration, up to ~64 KB (outSize-written frames × 4 bytes × extra channels) from a fresh allocation of an attacker-chosen size class. Demonstrated recovery of the full contents of previously freed heap allocations (Run B sentinel). In a shipping build this yields stale heap data — potentially heap pointers (ASLR defeat) and data resident in the content process — repeatable across iterations to scan many chunks.
• Preconditions: Victim loads a page that can start audio playback (autoplay permission or any transient user activation for play()); no other interaction required. No compromised process needed — plain web content. The test environment additionally used the mock cubeb backend and autoplay prefs only because the host has no audio device and no user gesture is possible under the harness.

ASAN Report

No ASAN crash (info-disclosure class; all reads stay inside live allocations). Proof strings from logs.stderr, content process:

Run A (unmodified ASAN build):
POCLOG summary-10s frames=2457600 ch0nz=16384 ch1nz=16384 sentinel=0 asanfill=0 other=16384 patterns=e4e4e4e4x16384
POCLOG POC-LEAK: junk in channel 1 asanfill=0 other=16384
(0xE4 = malloc_fill_byte=228 from build/sanitizers/AsanOptions.cpp — never-written malloc memory)

Run B (with source_patch.diff, ASAN fill disabled to emulate release allocator, after 0x4D5EC0DE heap spray):
POCLOG summary-10s frames=2457600 ch0nz=16384 ch1nz=16384 sentinel=16384 asanfill=0 other=0 patterns=
POCLOG POC-CONFIRMED: 4d5ec0de sprayed-heap sentinel recovered from resampled audio channel 1, count=16384 (uninitialized heap disclosure via AudioSegment::Resample uint32 truncation)

Deterministic signature in both runs: ch0nz=16384 = (16384*262145) mod 2^32; media currentTime frozen at 16384/262145 ≈ 0.062 s.

Comment 1

[Tom Ritter [:tjr]]

Attachment: crash_stack.txt

Comment 2

[Tom Ritter [:tjr]]

Attachment: fix.patch

Comment 3

[Tom Ritter [:tjr]]

Attachment: make_flac.py

Comment 4

[Tom Ritter [:tjr]]

Attachment: prefs.json

Comment 5

[Tom Ritter [:tjr]]

Attachment: source_patch.diff

Comment 6

[Tom Ritter [:tjr]]

Attachment: testcase.html

Comment 7

[Tom Ritter [:tjr]]

Attachment: prefs.js

Comment 8

[Tom Ritter [:tjr]]

This bug was filed automatically by an AI-powered security testing tool. The analysis, testcase, and any suggested patches were generated by an AI model and have NOT been verified by a human.

Please review all details carefully before triaging. The issue was confirmed by an independent verifier, but for non-ASAN issues, the verifier has been made less strict. Additionally, the root cause analysis and suggested fix may contain errors.

Comment 9

[C.M.Chang[:chunmin]]

Attachment: Bug 2059164 - Add a Web Audio test for resampling a low-rate media element

Plays a crafted 1 Hz stereo FLAC in an <audio> element captured into an
AudioContext at 262145 Hz, so the decoded chunk is resampled 1 Hz -> 262145 Hz.
The per-channel output size wraps uint32_t and channel 1 is left uninitialized
while mDuration still advertises channel 0's length, so a ScriptProcessorNode
delivers the never-written tail to content JS. On ASan builds that tail reads
back as the malloc-fill sentinel 0xe4e4e4e4, which makes the disclosure
observable as non-silent audio.

Extract the shared ASan malloc-fill detection into webaudio_asan_fill.js and
reuse it from the bug 2038465 test, which uses the same technique on the
decodeAudioData path.

This resample cannot legitimately produce audio - 16384 frames at 1 Hz becomes
over four billion frames at 262145 Hz - so a correct build emits silence and any
non-silent sample on channel 1 is disclosed memory. The test fails on the first
one and reports how many carry the malloc-fill sentinel, which tells
never-written heap apart from recycled heap contents. Silence is confirmed over
a number of delivered buffers rather than a wall-clock timeout, so the check
cannot elapse early on a loaded machine; the count starts at "playing", which
both a vulnerable and a fixed build reach because the file decodes either way,
so the margin covers only the delivery of the resampled chunk. A media load
error (as when an engine refuses the crafted FLAC, e.g. Chrome) is also accepted
as a pass. The autoplay prefs are set via SpecialPowers.pushPrefEnv.

Comment 10

[C.M.Chang[:chunmin]]

Attachment: (secure)

AudioSegment::Resample computed each chunk's per-channel output size as a
64-bit ceiling but stored it in a uint32_t. When a media element's sample rate
is far below the AudioContext rate, that size can exceed 2^32 and truncate,
under-allocating the per-channel buffers. Because the input frame count was
declared once outside the per-channel loop, the resampler's write-back then
left later channels resampled from zero input frames, and c.mDuration
advertised channel 0's length for every channel, disclosing the unwritten
channel tails to content.

Compute the size with CheckedInt and reject on overflow (returning
NS_ERROR_DOM_MEDIA_OVERFLOW_ERR) instead of truncating, and move the input
frame count inside the per-channel loop so every channel is resampled from the
full input. Resample and ResampleChunks now return nsresult; the
AudioDecoderInputTrack caller drops the segment on failure (the track fills
silence) and the SourceMediaTrack caller asserts success, consistent with its
rate-bounded inputs.

Comment 11

[BugBot [:suhaib / :marco]]

:chunmin, please update all release status flags to reflect the affected/unaffected/disabled state correctly. Which branches (beta, release, and/or ESR) are affected by this flaw?

Comment 12

[C.M.Chang[:chunmin]]

Attachment: Bug 2059164 - Test AudioSegment resample size rejection

Comment 13

[C.M.Chang[:chunmin]]

Comment on attachment 9620206 [details]
(secure)

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Moderate. The patch shows both halves of the defect — that an output size which does not fit uint32_t was previously truncated, and that the per-channel input count was shared so later channels ended up short of the duration the chunk advertises — so the trigger is discoverable from the diff combined with public API knowledge: a media file declaring a very low sample rate, captured into a high-rate AudioContext. Reaching the condition needs only standard web APIs with no timing dependency, but recovering anything useful rather than arbitrary residue requires heap grooming to place recognisable data, which is the additional factor that keeps this out of Easy.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No, the patch has been reviewed for information leaks. The fix's check-in comment is a one-line summary with no body, no identifier or code comment names the issue or its class, and the two test revisions are written in terms of the correctness property they assert. The tests are also held back deliberately and will land at least four weeks after the release containing the fix ships.
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: All supported branches are affected, verified by inspecting each branch rather than inferring from the regression range: Nightly 155, Beta 154, Release 153, ESR 153 and ESR 140 all carry both halves of the defect in dom/media/AudioSegment.cpp, and ESR 128 and ESR 115 carry the identical code inlined in dom/media/AudioSegment.h. Nothing is pref-gated, so the code is reachable wherever it exists. ESR 128 and ESR 115 cap the AudioContext sample rate at 192000 rather than 768000, which raises the minimum media block size needed from 5593 to 22370 frames but stays well inside what the container permits, so they are reachable as well; both branches nevertheless appear to be end-of-life (last updated 2025-09 and 2026-03), so please confirm against the current support list. The bug currently carries no status-firefoxNN flags; Nightly, Beta, Release, ESR 153 and ESR 140 should be set to affected.
• If not all supported branches, which bug introduced the flaw?: N/A — all supported branches are affected. For context, the shape dates to the 2014 rewrite of AudioSegment::Resample (bug 999267); bug 1713410 later widened the intermediate multiply to 64 bits but kept the 32-bit destination, so the narrowing survived.
• Do you have backports for the affected branches?: Not yet.
• If not, how different, hard to create, and risky will they be?: Low risk. The affected function is character-identical on Release, Beta, ESR 153 and ESR 140, so the patch should apply as-is or with a trivial offset adjustment. ESR 128 and ESR 115, if they are still in scope, would need the hunk relocated because the function is inlined in AudioSegment.h on those branches; that is mechanical and still low risk. ESR uplifts require separate approval.
• How likely is this patch to cause regressions; how much testing does it need?: Low. The change is confined to one function, its declaration and its two call sites. Behaviour is unchanged for any stream whose resampled size is representable, which is every real-world stream: resetting the per-channel input count is a no-op whenever the resampler consumes the whole chunk, which it does whenever the output buffer is large enough. The only behavioural change is that a chunk whose output size cannot be represented is now dropped, and the track fills silence, instead of being emitted mis-sized. Coverage is three new gtests pinning the accept and reject contract plus one Web Audio test; the full AudioSegment gtest suite (12/12) and the neighbouring Web Audio tests pass on an optimized AddressSanitizer build, and mach lint is clean.
• Is the patch ready to land after security approval is given?: Yes for the fix. The two test revisions are intentionally held back and will land at least four weeks after the release containing the fix ships.
• Is Android affected?: Yes. dom/media/AudioSegment.cpp is cross-platform and the affected path, a media element captured into a Web Audio graph, is available on GeckoView.

Drafted with the assistance of Claude Code — reviewed and approved by the patch author.

Comment 14

[BugBot [:suhaib / :marco]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 15

[C.M.Chang[:chunmin]]

Comment on attachment 9620206 [details]
(secure)

According to the latest sec-approval policy: https://firefox-source-docs.mozilla.org/bug-mgmt/processes/security-approval.html:

For the avoidance of doubt, core-security bug fixes can be landed by a developer without any explicit approval if:
...

• The bug has a sec-high rating, is a cross-process bug, but that target process is the GPU, RDD, GMP, Utility, Socket, or other non-Parent process
  ...

this fix requires no sec-approval since the uninitialized memory disclosure is in content-process only (FLAC decoding is in RDD).

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/73aeb6c2eb44
https://hg.mozilla.org/integration/autoland/rev/1cc4a9beadf7
Reject invalid AudioSegment resample sizes r=media-playback-reviewers,padenot

Comment 17

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/1cc4a9beadf7

Comment 18

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected, along with ESR.
:chunmin, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta and ESR approvals.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox154 and the ESR status flag(s) to wontfix.

For more information, please visit BugBot documentation.

Comment 19

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: sec-high uninitialized heap memory disclosure to web content (csectype-uninitialized). A page that can start audio playback can deterministically read uninitialized and recycled content-process heap memory: a media file declaring a very low sample rate, played in an <audio> element captured into a high-rate AudioContext, yields resampled buffers whose advertised duration exceeds what was actually written, and content JS reads the never-written tail back as audio samples through a ScriptProcessorNode. The reporter demonstrated recovery of the full contents of previously freed heap allocations of an attacker-chosen size class — up to roughly 64 KB per iteration, repeatable across iterations to scan further chunks, so potentially heap pointers (ASLR defeat) and other resident content-process data. No user interaction beyond loading the page and allowing playback is required.
• Code covered by automated testing?: no
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing: N/A
• Risk associated with taking this patch: low
• Explanation of risk level: The change is confined to one AudioSegment function, its declaration and its two call sites. Behaviour is unchanged for every stream whose resampled size is representable, which is every real-world stream. The only behavioural change is that a chunk whose output size is not representable is now dropped and the track fills silence, instead of being emitted mis-sized.
• String changes made/needed?: None
• Is Android affected?: yes

Comment 20

[C.M.Chang[:chunmin]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D315520

Comment 21

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined/Reason for urgency: sec-high uninitialized heap memory disclosure to web content (csectype-uninitialized). A page that can start audio playback can deterministically read uninitialized and recycled content-process heap memory: a media file declaring a very low sample rate, played in an <audio> element captured into a high-rate AudioContext, yields resampled buffers whose advertised duration exceeds what was actually written, and content JS reads the never-written tail back as audio samples through a ScriptProcessorNode. The reporter demonstrated recovery of the full contents of previously freed heap allocations of an attacker-chosen size class — up to roughly 64 KB per iteration, repeatable across iterations to scan further chunks, so potentially heap pointers (ASLR defeat) and other resident content-process data. No user interaction beyond loading the page and allowing playback is required.
• Code covered by automated testing?: no
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing: N/A
• Risk associated with taking this patch: low
• Explanation of risk level: The change is confined to one AudioSegment function, its declaration and its two call sites. Behaviour is unchanged for every stream whose resampled size is representable, which is every real-world stream. The only behavioural change is that a chunk whose output size is not representable is now dropped and the track fills silence, instead of being emitted mis-sized.
• String changes made/needed?: None
• Is Android affected?: yes

Comment 22

[C.M.Chang[:chunmin]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D315520

Comment 23

[Phabricator Automation]

firefox-esr153 Uplift Approval Request

• User impact if declined/Reason for urgency: sec-high uninitialized heap memory disclosure to web content (csectype-uninitialized). A page that can start audio playback can deterministically read uninitialized and recycled content-process heap memory: a media file declaring a very low sample rate, played in an <audio> element captured into a high-rate AudioContext, yields resampled buffers whose advertised duration exceeds what was actually written, and content JS reads the never-written tail back as audio samples through a ScriptProcessorNode. The reporter demonstrated recovery of the full contents of previously freed heap allocations of an attacker-chosen size class — up to roughly 64 KB per iteration, repeatable across iterations to scan further chunks, so potentially heap pointers (ASLR defeat) and other resident content-process data. No user interaction beyond loading the page and allowing playback is required.
• Code covered by automated testing?: no
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing: N/A
• Risk associated with taking this patch: low
• Explanation of risk level: The change is confined to one AudioSegment function, its declaration and its two call sites. Behaviour is unchanged for every stream whose resampled size is representable, which is every real-world stream. The only behavioural change is that a chunk whose output size is not representable is now dropped and the track fills silence, instead of being emitted mis-sized.
• String changes made/needed?: None
• Is Android affected?: yes

Comment 24

[C.M.Chang[:chunmin]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D315520

Comment 25

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: sec-high uninitialized heap memory disclosure to web content (csectype-uninitialized). A page that can start audio playback can deterministically read uninitialized and recycled content-process heap memory: a media file declaring a very low sample rate, played in an <audio> element captured into a high-rate AudioContext, yields resampled buffers whose advertised duration exceeds what was actually written, and content JS reads the never-written tail back as audio samples through a ScriptProcessorNode. The reporter demonstrated recovery of the full contents of previously freed heap allocations of an attacker-chosen size class — up to roughly 64 KB per iteration, repeatable across iterations to scan further chunks, so potentially heap pointers (ASLR defeat) and other resident content-process data. No user interaction beyond loading the page and allowing playback is required.
• Code covered by automated testing?: no
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing: N/A
• Risk associated with taking this patch: low
• Explanation of risk level: The change is confined to one AudioSegment function, its declaration and its two call sites. Behaviour is unchanged for every stream whose resampled size is representable, which is every real-world stream. The only behavioural change is that a chunk whose output size is not representable is now dropped and the track fills silence, instead of being emitted mis-sized.
• String changes made/needed?: None
• Is Android affected?: yes

Comment 26

[C.M.Chang[:chunmin]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D315520

Comment 27

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/f3ea46ed0a03
https://hg.mozilla.org/releases/mozilla-beta/rev/d3c050b0bcf8

Comment 28

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr153/rev/bb8cc494a65b

Comment 29

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/fa750fa085d5

Comment 30

[Ryan VanderMeulen [:RyanVM]]

Hi, an ESR115 patch is still needed for this bug.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D315520

Comment 32

[Phabricator Automation]

firefox-esr115 Uplift Approval Request

• User impact if declined/Reason for urgency: sec-high uninitialized heap memory disclosure to web content (csectype-uninitialized). A page that can start audio playback can deterministically read uninitialized and recycled content-process heap memory: a media file declaring a very low sample rate, played in an <audio> element captured into a high-rate AudioContext, yields resampled buffers whose advertised duration exceeds what was actually written, and content JS reads the never-written tail back as audio samples through a ScriptProcessorNode. The reporter demonstrated recovery of the full contents of previously freed heap allocations of an attacker-chosen size class — up to roughly 64 KB per iteration, repeatable across iterations to scan further chunks, so potentially heap pointers (ASLR defeat) and other resident content-process data. No user interaction beyond loading the page and allowing playback is required.
• Code covered by automated testing?: no
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing: N/A
• Risk associated with taking this patch: low
• Explanation of risk level: The change is confined to one AudioSegment function, its declaration and its two call sites. Behaviour is unchanged for every stream whose resampled size is representable, which is every real-world stream. The only behavioural change is that a chunk whose output size is not representable is now dropped and the track fills silence, instead of being emitted mis-sized.
• String changes made/needed?: None
• Is Android affected?: yes

Comment 33

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/5d0c8972b98c

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/f28bd043e396
https://hg.mozilla.org/integration/autoland/rev/180eb3b416df
Add a Web Audio test for resampling a low-rate media element r=media-playback-reviewers,padenot
https://github.com/mozilla-firefox/firefox/commit/87b3839d04a4
https://hg.mozilla.org/integration/autoland/rev/54001d5c446e
Test AudioSegment resample size rejection r=media-playback-reviewers,aosmond

Comment 35

[Goloman Adrian[:agoloman]]

https://hg.mozilla.org/mozilla-central/rev/180eb3b416df
https://hg.mozilla.org/mozilla-central/rev/54001d5c446e