Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: b728e584a883c12a86abe5d6932ad5a3715e4ccf
https://github.com/WebKit/WebKit/commit/b728e584a883c12a86abe5d6932ad5a3715e4ccf
Author: Youenn Fablet <you...@apple.com>
Date: 2024-08-02 (Fri, 02 Aug 2024)
Changed paths:
M
Source/WebCore/platform/mediarecorder/cocoa/MediaRecorderPrivateWriterCocoa.mm
Log Message:
-----------
heap-use-after-free |
WebCore::MediaRecorderPrivateWriter::flushCompressedSampleBuffers;
Detail::CallableWrapper::call; WTF::RunLoop::performWork)
rdar://129292824
Reviewed by Andy Estes.
Adding a weakThis check we missed when adopting ThreadSafefWeakPtr.
*
Source/WebCore/platform/mediarecorder/cocoa/MediaRecorderPrivateWriterCocoa.mm:
(WebCore::MediaRecorderPrivateWriter::fetchData):
Originally-landed-as: 272448.1073@safari-7618-branch (891cf8c9dbac).
rdar://132954379
Canonical link: https://commits.webkit.org/281790@main
Commit: 8da2eab7ffa0f22bb36806f41c043a0af5bc0973
https://github.com/WebKit/WebKit/commit/8da2eab7ffa0f22bb36806f41c043a0af5bc0973
Author: Dan Hecht <dan.he...@apple.com>
Date: 2024-08-02 (Fri, 02 Aug 2024)
Changed paths:
A JSTests/stress/regress-119545295.js
M Source/JavaScriptCore/runtime/InternalFunction.cpp
Log Message:
-----------
[JSC] JSGlobalObject::arrayStructureForIndexingTypeDuringAllocation may allow
creation of an undecided array with a Proxy object in the prototype chain
https://bugs.webkit.org/show_bug.cgi?id=274870
rdar://119545295
Reviewed by Keith Miller.
When constructing an array along this particular path, newTarget.prototype could
have a getter that induces a bad time. We need to check for this case and handle
it explicitly since the array isn't yet fully constructed and thus won't be
handled
by the having a bad time machinery.
* JSTests/stress/regress-119545295.js: Added.
(main.const.new_target):
* Source/JavaScriptCore/runtime/InternalFunction.cpp:
(JSC::InternalFunction::createSubclassStructure):
Originally-landed-as: 272448.1052@safari-7618-branch (d4c5d33ae803).
rdar://132954559
Canonical link: https://commits.webkit.org/281791@main
Commit: 4f4fdbf93a5952a568b92e2b690304aa24825fe2
https://github.com/WebKit/WebKit/commit/4f4fdbf93a5952a568b92e2b690304aa24825fe2
Author: Alex Christensen <achristen...@apple.com>
Date: 2024-08-02 (Fri, 02 Aug 2024)
Changed paths:
M Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WebSocket.mm
Log Message:
-----------
Disallow non-WebSocket use of ws and wss schemes at NetworkDataTaskCocoa level
rdar://81997401
Reviewed by Brady Eidson.
If you type wss://example.com into the URL bar of Safari, it will call
WKWebView.loadRequest
with that URL, and we will give it to CFNetwork, and it will successfully load
https://example.com
but in Chrome and Firefox it fails to load. We need it to also fail to load.
It used to
successfully load for legacy reasons related to the time before the existence
of the
NSURLSessionWebSocketTask API, but now that NSURLSessionWebSocketTask exists it
is no longer needed,
so when configuration._usesNWLoader is YES CFNetwork does this for us.
WebKit's use of NSURLSession
does not need to mix ws/wss and http/https schemes, so we can fail loads before
making an
NSURLSessionDataTask and our loading of http/https URLs still works because it
uses NSURLSessionDataTask
in the normal way, and our ws/wss URL "loading" still works because we use
NSURLSessionWebSocketTask
for those URLs through the JavaScript WebSocket object, the way WebSockets are
supposed to be created
from web content.
* Source/WebKit/NetworkProcess/cocoa/NetworkDataTaskCocoa.mm:
(WebKit::NetworkDataTaskCocoa::NetworkDataTaskCocoa):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WebSocket.mm:
(TestWebKitAPI::TEST):
Originally-landed-as: 272448.1042@safari-7618-branch (0a3f4d58c388).
rdar://132954656
Canonical link: https://commits.webkit.org/281792@main
Commit: ef46d74db28f933175a36860aae0d4433479fe62
https://github.com/WebKit/WebKit/commit/ef46d74db28f933175a36860aae0d4433479fe62
Author: Youenn Fablet <you...@apple.com>
Date: 2024-08-02 (Fri, 02 Aug 2024)
Changed paths:
M LayoutTests/http/wpt/webcodecs/videoFrame-rect-expected.txt
M LayoutTests/http/wpt/webcodecs/videoFrame-rect.html
M Source/WebCore/Modules/webcodecs/WebCodecsVideoFrameAlgorithms.cpp
Log Message:
-----------
WebCodecs VideoFrame Out-Of-Bounds Read
rdar://127438135
Reviewed by Jean-Yves Avenard.
When passing a NaN, our size error checks would be bypassed as comparing with
NaN returns false.
We add finite checks to x, y, width and height and add a corresponding test.
* LayoutTests/http/wpt/webcodecs/videoFrame-rect-expected.txt:
* LayoutTests/http/wpt/webcodecs/videoFrame-rect.html:
* Source/WebCore/Modules/webcodecs/WebCodecsVideoFrameAlgorithms.cpp:
(WebCore::parseVisibleRect):
Originally-landed-as: 272448.1035@safari-7618-branch (9c4e3c807b79).
rdar://132954751
Canonical link: https://commits.webkit.org/281793@main
Commit: b8956add13308d76eff2f87c28f99751af0d26ee
https://github.com/WebKit/WebKit/commit/b8956add13308d76eff2f87c28f99751af0d26ee
Author: Jean-Yves Avenard <j...@apple.com>
Date: 2024-08-02 (Fri, 02 Aug 2024)
Changed paths:
M Source/WebCore/PAL/ThirdParty/libavif/ThirdParty/dav1d/src/refmvs.c
Log Message:
-----------
Potential 'overread' issue commited to upstream dav1d
https://bugs.webkit.org/show_bug.cgi?id=274070 rdar://125547790
Reviewed by Youenn Fablet.
The refmvs_block struct is only 12 bytes large but it's accessed
using 16-byte unaligned loads in asm.
In order to avoid reading past the end of the allocated buffer
we therefore need to pad the allocation size by 4 bytes.
Fix from upstream 076955a1534bb49325a2252f6a1f494674e5363a
* Source/WebCore/PAL/ThirdParty/libavif/ThirdParty/dav1d/src/refmvs.c:
(dav1d_refmvs_init_frame):
Originally-landed-as: 272448.1027@safari-7618-branch (17ea9a97d6d4).
rdar://132954870
Canonical link: https://commits.webkit.org/281794@main
Compare: https://github.com/WebKit/WebKit/compare/0b2843995193...b8956add1330
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
