Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: e1a2977e3a8353fa61fcf484fdc10565c1562758
https://github.com/WebKit/WebKit/commit/e1a2977e3a8353fa61fcf484fdc10565c1562758
Author: Szymon Witamborski <[email protected]>
Date: 2025-06-13 (Fri, 13 Jun 2025)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.html
A
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.js
A
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.worker-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.worker.html
M Source/WebCore/platform/audio/cocoa/PlatformRawAudioDataCocoa.cpp
M Source/WebCore/platform/audio/gstreamer/PlatformRawAudioDataGStreamer.cpp
Log Message:
-----------
Fix AudioData.copyTo crashing on memcpy
https://bugs.webkit.org/show_bug.cgi?id=291070
Reviewed by Philippe Normand and Jean-Yves Avenard.
The memcpy branch of both GStreamer and Cocoa implementations were
not taking into account copyElementCount when calculating subSource.
This was causing overwriting the target if there was enough space
and crashes if the target was just-sized for the requested number
of elements to copy.
Moreover, only mono case for planar data was using memcpy while
stereo was using the unoptimised route. This was inconsistent with
the interleaved mode which was using memcpy for any number of
channels.
Add tests for mono, stereo, planar and interleaved data. Fix writing
beyond requested range and crashes by:
- taking into account copyElementCount when calulating subSource
- taking into account frame size when calculating frameOffsetInBytes
- taking into account sample size when calculating copyLengthInBytes
To unify handling of multichannel data between planar and interleaved
modes, enumerate more cases where it's safe to use memcpy and handle
the stereo planar case by adding a plane offset to the frame offset.
It's worth mentioning differences between GStreamer and Cocoa
implementations. While GST_AUDIO_INFO_BPF ("bytes per frame")
consistenly returns sampleSize * numberOfChannels, Cocoa's
CAAudioStreamDescription::bytesPerFrame() will be only multiplied
by number of channels in interleaved mode. Hence slight differences
in the way frame size and sample size are calculated in each
implementation.
It's also worth mentioning for context that copyElementCount is the
original options.frameCount already multiplied by number of channels
in case of interleaved copy. So copyLengthInBytes needs to only be
calculated from sample size, not the frame size.
*
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.js:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.worker-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/webcodecs/audio-data-copyTo.any.worker.html:
Added.
* Source/WebCore/platform/audio/cocoa/PlatformRawAudioDataCocoa.cpp:
(WebCore::PlatformRawAudioData::copyTo): Fixed writing out of bounds and
crashes.
* Source/WebCore/platform/audio/gstreamer/PlatformRawAudioDataGStreamer.cpp:
(WebCore::PlatformRawAudioData::copyTo): Fixed writing out of bounds and
crashes.
Canonical link: https://commits.webkit.org/296217@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
