Branch: refs/heads/webkitglib/2.46
Home: https://github.com/WebKit/WebKit
Commit: 183a03aa5b20fe9c4199dac11e3f7b7fe7f64317
https://github.com/WebKit/WebKit/commit/183a03aa5b20fe9c4199dac11e3f7b7fe7f64317
Author: Daniel Liu <[email protected]>
Date: 2025-01-27 (Mon, 27 Jan 2025)
Changed paths:
M LayoutTests/TestExpectations
M Source/JavaScriptCore/yarr/Yarr.h
Log Message:
-----------
Cherry-pick 289319@main (d30962803be5).
https://bugs.webkit.org/show_bug.cgi?id=285807
Increase Yarr matchLimit
https://bugs.webkit.org/show_bug.cgi?id=285807
rdar://143202375
Reviewed by Yusuke Suzuki.
The current limit of 1 million was set in 2010 for PCRE compatibility.
We should increase this limit since we want to be able to support larger
strings.
* Source/JavaScriptCore/yarr/Yarr.h:
Canonical link: https://commits.webkit.org/289319@main
Canonical link: https://commits.webkit.org/282416.389@webkitglib/2.46
Commit: c7ce8177027abaa968d200b1ce288cf1beab9f97
https://github.com/WebKit/WebKit/commit/c7ce8177027abaa968d200b1ce288cf1beab9f97
Author: Adrian Perez de Castro <[email protected]>
Date: 2025-01-27 (Mon, 27 Jan 2025)
Changed paths:
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/FrameLoader.h
M Source/WebCore/loader/cache/CachedResourceLoader.cpp
M Source/WebCore/page/SecurityPolicy.h
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKHTTPCookieStore.mm
Log Message:
-----------
Revert "Cherry-pick b7402f10b17c.
https://bugs.webkit.org/show_bug.cgi?id=283309";
This reverts commit 624da0c97614bbfbd5c65a3e2c5dd917d8171515.
Canonical link: https://commits.webkit.org/282416.390@webkitglib/2.46
Commit: 15b12f68ca84d6a9cf5c7eaaad003ef5fb5fa6ae
https://github.com/WebKit/WebKit/commit/15b12f68ca84d6a9cf5c7eaaad003ef5fb5fa6ae
Author: Yusuke Suzuki <[email protected]>
Date: 2025-01-28 (Tue, 28 Jan 2025)
Changed paths:
A JSTests/stress/regexp-filter-starts-with-bol-do-not-crash.js
M Source/JavaScriptCore/yarr/YarrPattern.cpp
Log Message:
-----------
Cherry-pick 288897@main (7ee275e0aed2).
https://bugs.webkit.org/show_bug.cgi?id=285939
[JSC] YarrPattern copyTerm can fail
https://bugs.webkit.org/show_bug.cgi?id=285939
rdar://142478433
Reviewed by Yijia Huang.
copyTerm can filter out starts-with-bol cases. So it may return nullptr.
We should skip copying term when it is returning a nullptr.
* JSTests/stress/regexp-filter-starts-with-bol-do-not-crash.js: Added.
* Source/JavaScriptCore/yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::copyDisjunction):
(JSC::Yarr::YarrPatternConstructor::copyTerm):
(JSC::Yarr::YarrPatternConstructor::quantifyAtom):
(JSC::Yarr::YarrPatternConstructor::optimizeBOL):
Canonical link: https://commits.webkit.org/288897@main
Canonical link: https://commits.webkit.org/282416.391@webkitglib/2.46
Commit: dca67aca922531d17a257a24005172f0bd4231cf
https://github.com/WebKit/WebKit/commit/dca67aca922531d17a257a24005172f0bd4231cf
Author: Youenn Fablet <[email protected]>
Date: 2025-01-28 (Tue, 28 Jan 2025)
Changed paths:
M Source/WebCore/Modules/mediastream/UserMediaRequest.cpp
Log Message:
-----------
Cherry-pick 283286.445@safari-7620-branch (bd990e20e91e). rdar://138483518
Remote Activation of Persistent Webcam Access without User Consent
rdar://138483518
Reviewed by Eric Carlson.
A getUserMedia call may happen before the document is stopped.
The document may be stopped between a source is created and the source is
attached to the document via MediaStreamTrack::create.
In that case, the source in the GPUProcess will be created but will never
be removed.
If the source is a clone of an active source in GPUProcess, this will
prevent the capture to stop when document is tear down.
To prevent this, if the context is stopped, we end the capture source in
UserMediaRequest::allow.
* Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:
(WebCore::UserMediaRequest::allow):
Canonical link: https://commits.webkit.org/283286.445@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.392@webkitglib/2.46
Commit: b957c152a07a739bbf3f7cfefac1d7a9e2b53155
https://github.com/WebKit/WebKit/commit/b957c152a07a739bbf3f7cfefac1d7a9e2b53155
Author: Sihui Liu <[email protected]>
Date: 2025-01-28 (Tue, 28 Jan 2025)
Changed paths:
M Source/WebCore/Modules/indexeddb/IDBDatabase.cpp
M Source/WebCore/Modules/indexeddb/IDBDatabase.h
M Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.cpp
M Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.h
M Source/WebCore/dom/ScriptExecutionContext.cpp
M Source/WebCore/dom/ScriptExecutionContext.h
Log Message:
-----------
Cherry-pick 283286.491@safari-7620-branch (ae369124fc38).
https://bugs.webkit.org/show_bug.cgi?id=283040
Pure virtual function called! in
WebCore::ScriptExecutionContext::postCrossThreadTask<WebCore::IDBDatabase
&,void (WebCore::IDBDatabase::*&)(const WebCore::IDBError &),const
WebCore::IDBError &>
https://bugs.webkit.org/show_bug.cgi?id=283040
rdar://139782420
Reviewed by Chris Dumez.
Crash log indicates IDBDatabase (IDBActiveDOMObject) can post task to
ScriptExecutionContext from the main thread when
context is being destroyed on a background thread. This is problematic
because ScriptExecutionContext is not
thread-safe and IDBDatabase is not supposed to access it directly from a
non-context thread. This patch fixes the issue
by posting task via ScriptExecutionContext::ensureOnContextThread function
instead, as the function acquires lock as
needed. Also this patch replaces raw pointer in m_databaseConnectionMap
with ThreadSafeWeakPtr, and make
IDBDatabase::m_isContextSuspended std::atomic for better thread safety.
* Source/WebCore/Modules/indexeddb/IDBDatabase.cpp:
(WebCore::IDBDatabase::IDBDatabase):
* Source/WebCore/Modules/indexeddb/IDBDatabase.h:
* Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.cpp:
(WebCore::IDBClient::IDBConnectionProxy::databaseFromConnectionIdentifier):
(WebCore::IDBClient::IDBConnectionProxy::fireVersionChangeEvent):
(WebCore::IDBClient::IDBConnectionProxy::didCloseFromServer):
(WebCore::IDBClient::IDBConnectionProxy::connectionToServerLost):
(WebCore::IDBClient::IDBConnectionProxy::registerDatabaseConnection):
(WebCore::IDBClient::IDBConnectionProxy::unregisterDatabaseConnection):
(WebCore::IDBClient::IDBConnectionProxy::setContextSuspended):
* Source/WebCore/Modules/indexeddb/client/IDBConnectionProxy.h:
* Source/WebCore/dom/ScriptExecutionContext.cpp:
(WebCore::ScriptExecutionContext::ensureOnContextThreadForCrossThreadTask):
* Source/WebCore/dom/ScriptExecutionContext.h:
Canonical link: https://commits.webkit.org/283286.491@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.393@webkitglib/2.46
Commit: 38542165fb738b03eec14fe9f9ab86a48f25d7d2
https://github.com/WebKit/WebKit/commit/38542165fb738b03eec14fe9f9ab86a48f25d7d2
Author: Youenn Fablet <[email protected]>
Date: 2025-01-28 (Tue, 28 Jan 2025)
Changed paths:
A LayoutTests/http/wpt/mediastream/getUserMedia-rvfc-remove-expected.txt
A LayoutTests/http/wpt/mediastream/getUserMedia-rvfc-remove.html
A
LayoutTests/http/wpt/mediastream/resources/getUserMedia-rvfc-remove-iframe.html
M Source/WebCore/html/HTMLVideoElement.cpp
M Source/WebCore/html/HTMLVideoElement.h
Log Message:
-----------
Cherry-pick 283286.513@safari-7620-branch (5e06ca5a17cd). rdar://140271547
J475d/24C76: Potential UAF in
HTMLVideoElement::serviceRequestVideoFrameCallbacks
rdar://140271547
Reviewed by Eric Carlson.
When servicing rvfc requests, we can navigate the document which will stop
the HTMLVideoElement.
This will clear the m_servicedVideoFrameRequests, which will delete the
requests.
To prevent this issue, we clear the call of VideoFrameRequest but do not
clear m_servicedVideoFrameRequests.
We remove VideoFrameRequest::cancelled as we now store a RefPtr callback.
* LayoutTests/http/wpt/mediastream/getUserMedia-rvfc-remove-expected.txt:
Added.
* LayoutTests/http/wpt/mediastream/getUserMedia-rvfc-remove.html: Added.
*
LayoutTests/http/wpt/mediastream/resources/getUserMedia-rvfc-remove-iframe.html:
Added.
* Source/WebCore/html/HTMLVideoElement.cpp:
(WebCore::HTMLVideoElement::cancelVideoFrameCallback):
(WebCore::HTMLVideoElement::stop):
(WebCore::HTMLVideoElement::serviceRequestVideoFrameCallbacks):
* Source/WebCore/html/HTMLVideoElement.h:
Canonical link: https://commits.webkit.org/283286.513@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.394@webkitglib/2.46
Commit: 9f74fd67d66290083bece63fcff5270489a6c16d
https://github.com/WebKit/WebKit/commit/9f74fd67d66290083bece63fcff5270489a6c16d
Author: Youenn Fablet <[email protected]>
Date: 2025-01-28 (Tue, 28 Jan 2025)
Changed paths:
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/svc_datarate_test.cc
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/test-data.mk
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/test-data.sha1
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_pickmode.c
M
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_svc_layercontext.c
Log Message:
-----------
Cherry-pick 283286.514@safari-7620-branch (f3ee0e300b5d).
https://bugs.webkit.org/show_bug.cgi?id=283040
Potential 'overflow, out of bounds' issue commited to upstream libwebrtc
rdar://138895814
Reviewed by Ryan Reno.
Cherry-picking of
https://github.com/webmproject/libvpx/commit/727319a77ffe68e9aacb08e09ae7151b3a8f70a3#diff-f535a6aec9d203c6ec84acfda8634fd78e50cd9e7fd3e05caaf247387bae9497R789.
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/svc_datarate_test.cc:
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/test-data.mk:
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/test-data.sha1:
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_pickmode.c:
*
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_svc_layercontext.c:
(vp9_one_pass_svc_start_layer):
Canonical link: https://commits.webkit.org/283286.514@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.395@webkitglib/2.46
Commit: b1adee51106f76bd26864f071a88164dabab4938
https://github.com/WebKit/WebKit/commit/b1adee51106f76bd26864f071a88164dabab4938
Author: Daniel Liu <[email protected]>
Date: 2025-01-28 (Tue, 28 Jan 2025)
Changed paths:
A JSTests/stress/resize-array-buffer-constantly.js
M Source/JavaScriptCore/assembler/AbstractMacroAssembler.h
M Source/JavaScriptCore/dfg/DFGSlowPathGenerator.h
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp
M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
Log Message:
-----------
Cherry-pick 283286.519@safari-7620-branch (21e99e5afce3).
https://bugs.webkit.org/show_bug.cgi?id=283142
Improve DFG_REGISTER_ALLOCATION_VALIDATION robustness
https://bugs.webkit.org/show_bug.cgi?id=283142
rdar://139826086
Reviewed by Yusuke Suzuki.
DFG_REGISTER_ALLOCATION_VALIDATION currently checks for branches, but does
not
consider slow paths. This leads to an oversight during validation that could
allow bugs to slip in.
* JSTests/stress/resize-array-buffer-constantly.js: Added.
(main):
* Source/JavaScriptCore/assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::RegisterAllocationOffset::checkOffset):
(JSC::AbstractMacroAssembler::checkRegisterAllocationAgainstSlowPathCall):
* Source/JavaScriptCore/dfg/DFGSlowPathGenerator.h:
(JSC::DFG::slowPathCall):
Canonical link: https://commits.webkit.org/283286.519@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.396@webkitglib/2.46
Commit: c4055152e94e8d6a93402bc8eeca0ba24265e8da
https://github.com/WebKit/WebKit/commit/c4055152e94e8d6a93402bc8eeca0ba24265e8da
Author: Youenn Fablet <[email protected]>
Date: 2025-01-28 (Tue, 28 Jan 2025)
Changed paths:
M Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp
M Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoEncoder.cpp
Log Message:
-----------
Cherry-pick 283286.533@safari-7620-branch (e975090744cf). rdar://140577403
Access to vpxDecoderQueueSingleton() is not-threadsafe
rdar://140577403
Reviewed by Jean-Yves Avenard.
Make use of std::call-once to initialize the queue only once.
* Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoDecoder.cpp:
(WebCore::vpxDecoderQueue):
* Source/WebCore/platform/libwebrtc/LibWebRTCVPXVideoEncoder.cpp:
(WebCore::vpxEncoderQueue):
Canonical link: https://commits.webkit.org/283286.533@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.397@webkitglib/2.46
Commit: 4bf806315d2d2d26071c337154a1785c3b14945c
https://github.com/WebKit/WebKit/commit/4bf806315d2d2d26071c337154a1785c3b14945c
Author: Youenn Fablet <[email protected]>
Date: 2025-01-28 (Tue, 28 Jan 2025)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
Cherry-pick 283286.534@safari-7620-branch (39b5b5e24156). rdar://140448767
`SubscribeToCookieChangeNotifications` and
`UnsubscribeFromCookieChangeNotifications` IPC messages do not verify cookie
access
rdar://140448767
Reviewed by Chris Dumez.
Add MESSAGE_CHECK to subscribeToCookieChangeNotifications and
unsubscribeFromCookieChangeNotifications as they may come from WebProcess.
These are similar checks to
NetworkConnectionToWebProcess::domCookiesForHost and are necessary for
subscribeToCookieChangeNotifications,
as it would otherwise allow a WebProcess to learn about new cookies.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::subscribeToCookieChangeNotifications):
(WebKit::NetworkConnectionToWebProcess::unsubscribeFromCookieChangeNotifications):
Canonical link: https://commits.webkit.org/283286.534@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.398@webkitglib/2.46
Commit: 425e495736d3b404a49a981751e8c72a199a166b
https://github.com/WebKit/WebKit/commit/425e495736d3b404a49a981751e8c72a199a166b
Author: Razvan Caliman <[email protected]>
Date: 2025-01-28 (Tue, 28 Jan 2025)
Changed paths:
M LayoutTests/http/tests/inspector/network/copy-as-curl.html
M Source/WebInspectorUI/UserInterface/Models/Resource.js
Log Message:
-----------
Cherry-pick 283286.565@safari-7620-branch (b52d52d68061).
https://bugs.webkit.org/show_bug.cgi?id=283718
Web Inspector: Use safer flag when copying request as cURL in Network tab
https://bugs.webkit.org/show_bug.cgi?id=283718
rdar://139882082
Reviewed by Anne van Kesteren.
Do not treat file-like paths like actual file paths.
* Source/WebInspectorUI/UserInterface/Models/Resource.js:
(WI.Resource):
Canonical link: https://commits.webkit.org/283286.565@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.399@webkitglib/2.46
Commit: c109482892ad0ab0b131047c952e93651f9c1edc
https://github.com/WebKit/WebKit/commit/c109482892ad0ab0b131047c952e93651f9c1edc
Author: Alex Christensen <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M Source/WebCore/platform/network/NetworkStorageSession.cpp
M Source/WebCore/workers/service/server/SWServer.cpp
Log Message:
-----------
Cherry-pick 283286.572@safari-7620-branch (fbcccfb28bc6). rdar://140118202
Add URL validity checks in NetworkStorageSession::shouldBlockCookies
rdar://140118202
Reviewed by Brent Fulgham.
If a comporomised web process sends IPC with an invalid URL, it can reach
NetworkStorageSession::shouldBlockCookies which should not allow access to
the cookies in that case.
SWServer::createScriptRequest needed a slight modification to stop it from
setting a firstPartyForCookies to an invalid URL like "https:".
* Source/WTF/wtf/cf/URLCF.cpp:
(WTF::URL::createCFURL const):
* Tools/TestWebKitAPI/Tests/WTF/cocoa/URLExtras.mm:
(TestWebKitAPI::TEST(WTF_URLExtras, InvalidURLToNSURL)):
Canonical link: https://commits.webkit.org/283286.572@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.400@webkitglib/2.46
Commit: c3b114f1d26467ad295594307e01a5b29d8f8b99
https://github.com/WebKit/WebKit/commit/c3b114f1d26467ad295594307e01a5b29d8f8b99
Author: Daniel Liu <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
A JSTests/wasm/stress/array-init-data-bounds.js
M Source/JavaScriptCore/wasm/WasmOperationsInlines.h
Log Message:
-----------
Cherry-pick 283286.574@safari-7620-branch (8fbbb5e792fb).
https://bugs.webkit.org/show_bug.cgi?id=284332
Update incorrect bounds check in arrayInitData that could lead to overflow
https://bugs.webkit.org/show_bug.cgi?id=284332
rdar://140773517
Reviewed by Yusuke Suzuki.
arrayInitData's operation currently checks that the source index plus the
size
has not overflowed. However, size is the number of array elements, meaning
that
size * elementSize could potentially overflow later on.
* Source/JavaScriptCore/wasm/WasmOperationsInlines.h:
(JSC::Wasm::arrayInitData):
Canonical link: https://commits.webkit.org/283286.574@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.401@webkitglib/2.46
Commit: 9943ba532c29f4f05b5d1025929c04b787d68d4e
https://github.com/WebKit/WebKit/commit/9943ba532c29f4f05b5d1025929c04b787d68d4e
Author: David Degazio <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
A JSTests/wasm/stress/tail-call-should-consume-stack-in-bbq.js
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
Log Message:
-----------
Cherry-pick 283286.575@safari-7620-branch (ca83d835b014).
https://bugs.webkit.org/show_bug.cgi?id=284159
[WASM] Tail calls should consume expression stack after call in BBQ
https://bugs.webkit.org/show_bug.cgi?id=284159
rdar://141164805
Reviewed by Yusuke Suzuki.
Adds a loop to consume expression stack elements after we
generate a tail call (direct or indirect) in BBQ. This is
consistent with our behavior in the return opcode, and
prevents register bindings from persisting into the
subsequent unreachable code.
* JSTests/wasm/stress/tail-call-should-consume-stack-in-bbq.js: Added.
* Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::emitTailCall):
(JSC::Wasm::BBQJITImpl::BBQJIT::emitIndirectTailCall):
Canonical link: https://commits.webkit.org/283286.575@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.402@webkitglib/2.46
Commit: a989dd7662a4a70292beeb296765210cc8d05d66
https://github.com/WebKit/WebKit/commit/a989dd7662a4a70292beeb296765210cc8d05d66
Author: Abrar Rahman Protyasha <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h
M Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm
Log Message:
-----------
Cherry-pick 283286.578@safari-7620-branch (de6e83ab1f4d).
https://bugs.webkit.org/show_bug.cgi?id=284408
OOB crash under WebKit::dataProviderGetBytesAtPositionCallback during
off-main-thread incremental PDF loading
https://bugs.webkit.org/show_bug.cgi?id=284408
rdar://131110151
Reviewed by Simon Fraser.
We occasionally crash trying to memcpy a buffer for incremental loading
data provision. Here's a representative trace:
```
Thread 4 Crashed:: Dispatch queue: LinearizedPagePreload
0 _platform_memmove + 96
1 void WTF::memcpySpan<unsigned char, 18446744073709551615ul, unsigned char
const, 18446744073709551615ul>(std::__1::span<unsigned char,
18446744073709551615ul>, std::__1::span<unsigned char const,
18446744073709551615ul>) + 16
2
WebKit::PDFIncrementalLoader::dataProviderGetBytesAtPosition(std::__1::span<unsigned
char, 18446744073709551615ul>, long long) + 52
3 WebKit::dataProviderGetBytesAtPositionCallback(void*, void*, long long,
unsigned long) + 308
4 provider_get_bytes_at_position + 84
5 CGDataProviderDirectGetBytesAtPositionInternal + 308
```
While we don't have a reproducible case yet, some analysis of the
incremental loading code suggests there is a small flaw in the threading
model for PDFPluginBase::dataSpanForRange() callers. That method secures
a lock to produce the data span, but if a load stream fails after a
caller gets the data span and before accessing said span, callers may
end up referencing null data.
This patch is a speculative fix for this issue. We teach
dataSpanForRange to accept a completion handler, which callers will
adopt as a substitute for the work they would have done with the data
span they expect to receive. The completion handler can then be called
while the data lock is still held.
This fix exposed an issue with the threading model for debug logging,
since our logging unconditionally jumps to the main thread and requests
to hold the data lock, thus deadlocking the web process. We address this
by securing a copy of m_streamedBytes before jumping across thread
boundaries -- see PDFPluginBase::streamedBytesForDebugLogging(). This
method skirts around thread safety analysis but ensures that the data
lock _is secured_ by the calling thread, else asserting.
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFIncrementalLoader.mm:
(WebKit::ByteRangeRequest::completeUnconditionally):
(WebKit::PDFIncrementalLoader::dataSpanForRange const):
(WebKit::PDFIncrementalLoader::requestCompleteIfPossible):
(WebKit::PDFIncrementalLoader::dataProviderGetBytesAtPosition):
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.h:
* Source/WebKit/WebProcess/Plugins/PDF/PDFPluginBase.mm:
(WebKit::PDFPluginBase::dataSpanForRange const):
(WebKit::PDFPluginBase::incrementalLoaderLog):
(WebKit::PDFPluginBase::incrementalLoaderLogWithBytes):
Canonical link: https://commits.webkit.org/283286.578@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.403@webkitglib/2.46
Commit: f9dd3fa8aa8364544bf9781be5a9c6dd27b56ceb
https://github.com/WebKit/WebKit/commit/f9dd3fa8aa8364544bf9781be5a9c6dd27b56ceb
Author: Charlie Wolfe <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
Cherry-pick 283286.585@safari-7620-branch (dc56db7312eb).
https://bugs.webkit.org/show_bug.cgi?id=284434
NetworkConnectionToWebProcess::performSynchronousLoad should have a Data
Isolation check
https://bugs.webkit.org/show_bug.cgi?id=284434
rdar://141255904
Reviewed by Alex Christensen.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::performSynchronousLoad):
Canonical link: https://commits.webkit.org/283286.585@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.404@webkitglib/2.46
Commit: 82a0a51badee66d09f73cc66c02530e557ab167c
https://github.com/WebKit/WebKit/commit/82a0a51badee66d09f73cc66c02530e557ab167c
Author: Matthew Finkel <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M
LayoutTests/http/tests/security/file-system-access-via-dataTransfer-expected.txt
M LayoutTests/http/tests/security/file-system-access-via-dataTransfer.html
A
LayoutTests/platform/mac-wk1/http/tests/security/file-system-access-via-dataTransfer-expected.txt
M Source/WebCore/Modules/entriesapi/DOMFileSystem.cpp
Log Message:
-----------
Cherry-pick 283286.586@safari-7620-branch (bddd7907adf8).
https://bugs.webkit.org/show_bug.cgi?id=283117
Enforce m_rootPath for remaining DOMFileSystem file access
https://bugs.webkit.org/show_bug.cgi?id=283117
rdar://139533231
Reviewed by Chris Dumez.
This is a follow-up to 276184@main where I added validation in
DOMFileSystem::get{Entry,File}. That missed the ability to leverage
getParent
and listDirectory for testing if a directory exists. This patch closes that
hole.
*
LayoutTests/http/tests/security/file-system-access-via-dataTransfer-expected.txt:
* LayoutTests/http/tests/security/file-system-access-via-dataTransfer.html:
*
LayoutTests/platform/mac-wk1/http/tests/security/file-system-access-via-dataTransfer-expected.txt:
Copied from
LayoutTests/http/tests/security/file-system-access-via-dataTransfer-expected.txt.
* Source/WebCore/Modules/entriesapi/DOMFileSystem.cpp:
(WebCore::DOMFileSystem::listDirectory):
(WebCore::DOMFileSystem::getParent):
Canonical link: https://commits.webkit.org/283286.586@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.405@webkitglib/2.46
Commit: 95847ca6555053d5ca05d3f4e71a11f3eb792f7c
https://github.com/WebKit/WebKit/commit/95847ca6555053d5ca05d3f4e71a11f3eb792f7c
Author: Nitin Mahendru <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M Source/WebCore/bindings/js/SerializedScriptValue.cpp
Log Message:
-----------
Cherry-pick 283286.591@safari-7620-branch (b31ed7f5f527).
https://bugs.webkit.org/show_bug.cgi?id=284558
Add fail() to correctly terminate deserialization
https://bugs.webkit.org/show_bug.cgi?id=284558
rdar://140885860
Reviewed by Pascoe.
Just returning JSValue() will not stop the deserialization process.
* Source/WebCore/bindings/js/SerializedScriptValue.cpp:
(WebCore::CloneDeserializer::readTerminal):
Canonical link: https://commits.webkit.org/283286.591@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.406@webkitglib/2.46
Commit: 2537da92aea17c083793bd8d11a23548f4ebee90
https://github.com/WebKit/WebKit/commit/2537da92aea17c083793bd8d11a23548f4ebee90
Author: Qianlang Chen <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M Source/WebCore/inspector/agents/InspectorWorkerAgent.cpp
M Source/WebCore/inspector/agents/InspectorWorkerAgent.h
M Source/WebCore/inspector/agents/page/PageWorkerAgent.cpp
M Source/WebCore/inspector/agents/page/PageWorkerAgent.h
M Source/WebCore/inspector/agents/worker/WorkerWorkerAgent.cpp
M Source/WebCore/inspector/agents/worker/WorkerWorkerAgent.h
M Source/WebCore/workers/WorkerInspectorProxy.cpp
M Source/WebCore/workers/WorkerInspectorProxy.h
Log Message:
-----------
Cherry-pick 283286.596@safari-7620-branch (e57de05ab1d3).
https://bugs.webkit.org/show_bug.cgi?id=284327
UAF may occur in WorkerInspectorProxy::sendMessageFromWorkerToFrontend
https://bugs.webkit.org/show_bug.cgi?id=284327
rdar://140133704
Reviewed by Chris Dumez.
WorkerInspectorProxy::m_pageChannel is a raw pointer and is prone to
being UAF. However, making the PageChannel class ref-counted is not
straightforward as WorkerInspectorController uses an array of
`std::unique_ptr`s to record that PageChannel and other agent objects
(https://github.com/WebKit/WebKit/blob/3fa7ffbf74469b65cf23a05c1780319954860f3c/Source/WebCore/inspector/WorkerInspectorController.cpp#L217,
where WorkerWorkerAgent subclasses InspectorWorkerAgent and PageChannel).
My solution is to make PageChannel ref-counted but also make the class
pointed to by a std::unique_ptr own a PageChannel rather than inheriting
from PageChannel. That way, we can maintain unique_ptrs to
InspectorWorkerAgent and still have RefPtrs to PageChannel.
* Source/WebCore/inspector/agents/InspectorWorkerAgent.h:
* Source/WebCore/inspector/agents/InspectorWorkerAgent.cpp:
(WebCore::InspectorWorkerAgent::InspectorWorkerAgent):
(WebCore::InspectorWorkerAgent::~InspectorWorkerAgent):
(WebCore::InspectorWorkerAgent::connectToWorkerInspectorProxy):
(WebCore::InspectorWorkerAgent::PageChannel::create):
(WebCore::InspectorWorkerAgent::PageChannel::PageChannel):
(WebCore::InspectorWorkerAgent::PageChannel::detachFromParentAgent):
- Make the PageChannel class ref-counted.
(WebCore::InspectorWorkerAgent::frontendDispatcher):
(WebCore::InspectorWorkerAgent::sendMessageFromWorkerToFrontend): Deleted.
(WebCore::InspectorWorkerAgent::PageChannel::sendMessageFromWorkerToFrontend):
- Reroute the sendMessageFromWorkerToFrontend method since now
InspectorWorkerAgent owns the page channel instead of being one.
* Source/WebCore/workers/WorkerInspectorProxy.h:
* Source/WebCore/workers/WorkerInspectorProxy.cpp:
(WebCore::WorkerInspectorProxy::sendMessageFromWorkerToFrontend):
* Source/WebCore/inspector/agents/page/PageWorkerAgent.cpp:
* Source/WebCore/inspector/agents/page/PageWorkerAgent.h:
* Source/WebCore/inspector/agents/worker/WorkerWorkerAgent.cpp:
* Source/WebCore/inspector/agents/worker/WorkerWorkerAgent.h:
- Enable the InspectorWorkerAgent::PageChannel class to be
ref-counted.
Canonical link: https://commits.webkit.org/283286.596@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.407@webkitglib/2.46
Commit: ed8789d97e834f2a064c98cef05557c3f763fd1f
https://github.com/WebKit/WebKit/commit/ed8789d97e834f2a064c98cef05557c3f763fd1f
Author: Sihui Liu <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M Source/WTF/wtf/CrossThreadTask.h
M Source/WTF/wtf/TypeTraits.h
Log Message:
-----------
Cherry-pick 0a6d878611ce. <bug>
Web content process crash in WebCore::Event::~Event
rdar://141997895
Reviewed by Chris Dumez.
rdar://139782420 made IDBDatabase subclass
ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr. However,
createCrossThreadTask() does not capture RefPtr for derived classes of
ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr.
To fix it, make sure createCrossThreadTask() creates RefPtr when ref()
member function is available.
* Source/WTF/wtf/CrossThreadTask.h:
(WTF::createCrossThreadTask):
* Source/WTF/wtf/TypeTraits.h:
Canonical link: https://commits.webkit.org/283286.605@safari-7620-branch
Canonical link:
https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/282416.408@webkitglib/2.46
Compare: https://github.com/WebKit/WebKit/compare/f4538ae78a3b...ed8789d97e83
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
