Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 992e017dca6787c34e526328675c2ddd658469fd
https://github.com/WebKit/WebKit/commit/992e017dca6787c34e526328675c2ddd658469fd
Author: Chris Dumez <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
M Source/WTF/wtf/MappedFileData.h
M Source/WTF/wtf/posix/FileHandlePOSIX.cpp
M Source/WTF/wtf/posix/MappedFileDataPOSIX.cpp
M Source/WTF/wtf/win/FileHandleWin.cpp
M Source/WTF/wtf/win/MappedFileDataWin.cpp
M Source/WebCore/platform/network/BlobData.cpp
M Source/WebCore/platform/network/BlobData.h
M Source/WebCore/platform/network/BlobDataFileReference.cpp
M Source/WebCore/platform/network/BlobDataFileReference.h
M Tools/TestWebKitAPI/Tests/WTF/FileSystem.cpp
Log Message:
-----------
Cherry-pick 5b1739a247ed. https://bugs.webkit.org/show_bug.cgi?id=312734
Cross-Thread Destruction of BlobData Races Non-Thread-Safe
RefCounted<BlobDataFileReference> Leads to UAF
https://bugs.webkit.org/show_bug.cgi?id=312734
rdar://174674094
Reviewed by Ryosuke Niwa.
BlobData was ThreadSafeRefCounted but contained data members that were
not safe to destroy on other threads like a String and a
`RefPtr<BlobDataFileReference>` (BlobDataFileReference only subclasses
RefCounted). For thread safety, both BlobData and BlobDataFileReference
now subclass `ThreadSafeRefCounted<T, WTF::DestructionThread::Main>` so
that not only their ref-counting is atomic but also to guarantee that
they get destroyed on the main thread (since they are always constructed
on the main thread). This is important given that they have String
data members.
Also, as further hardening recommended by the AI, update MappedFileData
to be able to distinguish empty data and invalid data.
* Source/WTF/wtf/MappedFileData.h:
(WTF::FileSystemImpl::MappedFileData::emptyFile):
(WTF::FileSystemImpl::MappedFileData::operator bool const):
(WTF::FileSystemImpl::MappedFileData::leakHandle):
(WTF::FileSystemImpl::MappedFileData::fileMapping const):
* Source/WTF/wtf/posix/FileHandlePOSIX.cpp:
(WTF::FileSystemImpl::FileHandle::map):
* Source/WTF/wtf/posix/MappedFileDataPOSIX.cpp:
(WTF::FileSystemImpl::MappedFileData::MappedFileData):
* Source/WTF/wtf/win/FileHandleWin.cpp:
(WTF::FileSystemImpl::FileHandle::map):
* Source/WTF/wtf/win/MappedFileDataWin.cpp:
(WTF::FileSystemImpl::MappedFileData::MappedFileData):
* Source/WebCore/platform/network/BlobData.cpp:
(WebCore::BlobData::BlobData):
* Source/WebCore/platform/network/BlobData.h:
* Source/WebCore/platform/network/BlobDataFileReference.cpp:
(WebCore::BlobDataFileReference::BlobDataFileReference):
* Source/WebCore/platform/network/BlobDataFileReference.h:
Identifier: 305413.709@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.820@webkitglib/2.52
Commit: 2e12e62ce9ba37724cebb854d5acea3b1a65f6ee
https://github.com/WebKit/WebKit/commit/2e12e62ce9ba37724cebb854d5acea3b1a65f6ee
Author: Shu-yu Guo <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
A JSTests/stress/regress-174463162.js
M Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h
M Source/JavaScriptCore/jit/GCAwareJITStubRoutine.h
M Source/JavaScriptCore/tools/JSDollarVM.cpp
M Source/JavaScriptCore/tools/JSDollarVM.h
Log Message:
-----------
Cherry-pick d577d4001218. https://bugs.webkit.org/show_bug.cgi?id=312610
[JSC] Override isValid() on AdaptiveValueStructureStubClearingWatchpoint
https://bugs.webkit.org/show_bug.cgi?id=312610
rdar://174463162
Reviewed by Keith Miller.
AdaptiveValueStructureStubClearingWatchpoint doesn't override isValid().
The base class fire() calls isValid() before dereferencing m_key.object()
via m_key.isWatchable() and install(). The default isValid() returns true,
allowing fire() to dereference a potentially dead m_key.object() when the
owning stub routine's CodeBlock has been collected.
The IC code paths that exercise this are not directly exercisable from vanilla
JS, so a $vm.installStructureStubClearingWatchpointWithDeadOwner is added to
simulate the conditions that would trigger this bug.
Test: JSTests/stress/regress-174463162.js
* JSTests/stress/regress-174463162.js: Added.
(main):
* Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:
* Source/JavaScriptCore/jit/GCAwareJITStubRoutine.h:
* Source/JavaScriptCore/tools/JSDollarVM.cpp:
(JSC::JSDollarVMHelper::setOwnerIsDead):
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSDollarVM::finishCreation):
(JSC::JSDollarVM::visitChildrenImpl):
* Source/JavaScriptCore/tools/JSDollarVM.h:
Identifier: 305413.706@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.821@webkitglib/2.52
Commit: c58fda5a7d9f5aef70ba4064177c668b873f6106
https://github.com/WebKit/WebKit/commit/c58fda5a7d9f5aef70ba4064177c668b873f6106
Author: Anthony Tarbinian <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
A
LayoutTests/ipc/networksindexeddb-close-connection-during-version-change-expected.txt
A
LayoutTests/ipc/networksindexeddb-close-connection-during-version-change.html
M Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabase.cpp
M Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabase.h
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp
Log Message:
-----------
Cherry-pick 6b2393e40648. https://bugs.webkit.org/show_bug.cgi?id=312391
Reject IndexedDB transactions during version change operation
https://bugs.webkit.org/show_bug.cgi?id=312391
rdar://173799670
Reviewed by Sihui Liu.
When an IndexedDB connection is closed while a version
change transaction is active, UniqueIDBDatabase::connectionClosedFromClient
successfully closes the version change transaction however it does
not clear any other pending transactions due to an early return
when clearing version change transactions.
Instead of being defensive and clearing the pending transaciton
in the case of the early return, we should reject any incoming
transactions which come on a version change connection.
Only whenever a version change operation completes, can
a new transaction be established. So, this patch rejects any
incoming transactions which come while a version change operation
is active.
The IndexedDB spec describes the steps for starting a new transaction:
The transaction(storeNames, mode, options) method steps are:
1. If a live upgrade transaction is associated with the connection,
throw an "InvalidStateError" DOMException.
https://w3c.github.io/IndexedDB/#dom-idbdatabase-transaction
This check already happens in the web process during
IDBDatabase::transaction where it returns an "InvalidStateError"
in this state.
However, this doesn't account for a compromised web process
who avoids this client side check and makes it across IPC
to invoke transaction creation in the NetworkProcess.
This patch adds a check for this scenario of a comprimised web
process who manages to start a new transaction during a
version change, if this is detected, we return early and
don't move forward with creating the transaction
This patch checks that the current connection isn't the
stored UniqueIDBDatabase::m_versionChangeDatabaseConnection.
That member variable will point to the active version change connection,
if any, and it is cleared when the version change completes.
It also checks if m_versionChangeTransaction is non-null
since it will only be null once the version change transaction
is completed.
*
LayoutTests/ipc/networksindexeddb-close-connection-during-version-change-expected.txt:
Added.
*
LayoutTests/ipc/networksindexeddb-close-connection-during-version-change.html:
Added.
* Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabase.cpp:
(WebCore::IDBServer::UniqueIDBDatabase::isVersionChangeTransactionActive const):
* Source/WebCore/Modules/indexeddb/server/UniqueIDBDatabase.h:
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
(WebKit::NetworkStorageManager::establishTransaction):
(WebKit::NetworkStorageManager::databaseConnectionPendingClose):
Identifier: 305413.734@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.822@webkitglib/2.52
Commit: 6e418f9536458b073e50f895f7f9d9065a293765
https://github.com/WebKit/WebKit/commit/6e418f9536458b073e50f895f7f9d9065a293765
Author: Shu-yu Guo <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
A JSTests/stress/dfg-ensure-absence-cached-dictionary-then.js
M Source/JavaScriptCore/dfg/DFGGraph.cpp
M Source/JavaScriptCore/runtime/Structure.h
Log Message:
-----------
Cherry-pick 343b8326d944. https://bugs.webkit.org/show_bug.cgi?id=313265
[JSC] Do not cache property absence on dictionaries
https://bugs.webkit.org/show_bug.cgi?id=313265
rdar://175520268
Reviewed by Yusuke Suzuki.
Structures with CachedDictionaryKind can add new properties without
transitioning structures. Therefore, property absences are not cacheable. This
PR fixes a bug in DFG which incorrectly caches property absences on structures
with CachedDictionaryKind.
Test: JSTests/stress/dfg-ensure-absence-cached-dictionary-then.js
* JSTests/stress/dfg-ensure-absence-cached-dictionary-then.js: Added.
(createObject1):
(createObject2):
(opt):
(main):
* Source/JavaScriptCore/dfg/DFGGraph.cpp:
(JSC::DFG::Graph::tryEnsureAbsence):
* Source/JavaScriptCore/runtime/Structure.h:
(JSC::Structure::propertyAccessesAreCacheableForAbsence):
Identifier: 305413.731@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.823@webkitglib/2.52
Commit: f158c0f7a99cc57c2e970e7e0fc253ac848ea870
https://github.com/WebKit/WebKit/commit/f158c0f7a99cc57c2e970e7e0fc253ac848ea870
Author: Said Abou-Hallawa <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
M Source/WebCore/platform/graphics/ImageBufferDisplayListBackend.h
M Source/WebCore/platform/graphics/cg/ImageBufferCGPDFDocumentBackend.h
M Source/WebKit/GPUProcess/graphics/RemoteImageBuffer.cpp
Log Message:
-----------
Cherry-pick acb3c0834c1a. https://bugs.webkit.org/show_bug.cgi?id=312835
putPixelBuffer() and getPixelBuffer() should never be called for PDF and
DisplayList ImageBufferBackends
https://bugs.webkit.org/show_bug.cgi?id=312835
rdar://174740190
Reviewed by Simon Fraser.
Currently these functions debug ASSERT only. In the release build,
getPixelBuffer()
returns without filling the PixelBuffer with zeros. If the ImageBuffer is
remote,
the returned PixelBuffer will be serialized uninitialized to the WebProcess.
RemoteImageBuffer should MESSAGE_CHECK, the backend has pixels. The calls to
putPixelBuffer() and getPixelBuffer() should not be made in normal snapshotting
scenarios.
* Source/WebCore/platform/graphics/ImageBufferDisplayListBackend.h:
* Source/WebCore/platform/graphics/cg/ImageBufferCGPDFDocumentBackend.h:
* Source/WebKit/GPUProcess/graphics/RemoteImageBuffer.cpp:
(WebKit::RemoteImageBuffer::getPixelBuffer):
(WebKit::RemoteImageBuffer::putPixelBuffer):
Identifier: 305413.751@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.824@webkitglib/2.52
Commit: fe9df9caf70ae452871ee17002675eda762b5706
https://github.com/WebKit/WebKit/commit/fe9df9caf70ae452871ee17002675eda762b5706
Author: Timothy Hatcher <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
M
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPIRuntimeCocoa.mm
M
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPITabsCocoa.mm
Log Message:
-----------
Cherry-pick 343f135c4791. https://bugs.webkit.org/show_bug.cgi?id=313465
Web Extensions: stack-use-after-return of &handledCount in WebExtensionContext
async-reply lambdas.
https://webkit.org/b/313465
rdar://175672573
Reviewed by Brian Weinstein.
Fix use-after-return of handledCount in runtimeConnect, runtimeWebPageConnect,
and tabsConnect. The stack-local
counter was captured by reference into async-reply lambdas that execute after
the enclosing frame returns.
Use Box<size_t> to heap-allocate the shared counter instead.
*
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPIRuntimeCocoa.mm:
(WebKit::WebExtensionContext::runtimeConnect):
(WebKit::WebExtensionContext::runtimeWebPageConnect):
*
Source/WebKit/UIProcess/Extensions/Cocoa/API/WebExtensionContextAPITabsCocoa.mm:
(WebKit::WebExtensionContext::tabsConnect):
Identifier: 305413.749@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.825@webkitglib/2.52
Commit: 1d5b9c09d536c7b4860dc5ba7c9bdc4e19d14caa
https://github.com/WebKit/WebKit/commit/1d5b9c09d536c7b4860dc5ba7c9bdc4e19d14caa
Author: Ruthvik Konda <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
A
LayoutTests/ipc/dynamic-content-scaling-display-list-during-prepare-for-display-expected.txt
A
LayoutTests/ipc/dynamic-content-scaling-display-list-during-prepare-for-display.html
M LayoutTests/platform/visionos/TestExpectations
M Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.cpp
Log Message:
-----------
Cherry-pick 5364d0966d20. https://bugs.webkit.org/show_bug.cgi?id=313460
Dynamic content scaling display lists should not be requested while preparing
for display
https://bugs.webkit.org/show_bug.cgi?id=313460
rdar://174414109
Reviewed by Simon Fraser.
The WebProcess can send DynamicContentScalingDisplayList while
prepareBufferForDisplay
is still active on the GPU Process. This is semantically invalid.
DynamicContentScalingDisplayList calls dynamicContentScalingDisplayList() on the
front buffer, which calls releaseGraphicsContext() — destroying the graphics
context
that prepareBufferForDisplay is actively using through m_context. This leads to
a
dangling reference.
This is a variant of rdar://167565825 (939a2f7876f3) that survives the existing
MESSAGE_CHECK on markSurfacesVolatile. Only reachable on PLATFORM(VISION) where
ENABLE(RE_DYNAMIC_CONTENT_SCALING) is defined.
To fix, we add a MESSAGE_CHECK to reject when dynamicContentScalingDisplayList
is
called while drawing is ongoing, mirroring the existing guard on
markSurfacesVolatile.
Test: ipc/dynamic-content-scaling-display-list-during-prepare-for-display.html
*
LayoutTests/ipc/dynamic-content-scaling-display-list-during-prepare-for-display-expected.txt:
Added.
*
LayoutTests/ipc/dynamic-content-scaling-display-list-during-prepare-for-display.html:
Added.
* LayoutTests/platform/visionos/TestExpectations:
* Source/WebKit/GPUProcess/graphics/RemoteImageBufferSet.cpp:
(WebKit::RemoteImageBufferSet::dynamicContentScalingDisplayList):
Identifier: 305413.743@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.826@webkitglib/2.52
Commit: 8f4ad594b473a76375f785d44d993a7300344700
https://github.com/WebKit/WebKit/commit/8f4ad594b473a76375f785d44d993a7300344700
Author: Kiara Rose <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
M
Source/WebKit/Shared/Extensions/WebExtensionRegisteredScriptsSQLiteStore.cpp
M Source/WebKit/Shared/Extensions/WebExtensionRegisteredScriptsSQLiteStore.h
M
Source/WebKit/UIProcess/Extensions/WebExtensionDeclarativeNetRequestSQLiteStore.cpp
M
Source/WebKit/UIProcess/Extensions/WebExtensionDeclarativeNetRequestSQLiteStore.h
Log Message:
-----------
Cherry-pick c85584f296ce. https://bugs.webkit.org/show_bug.cgi?id=312319
heap-use-after-free in WebExtensionRegisteredScriptsSQLiteStore::addScripts
https://bugs.webkit.org/show_bug.cgi?id=312319
rdar://174530074
Reviewed by Timothy Hatcher.
WebExtensionRegisteredScriptsSQLiteStore::addScripts and
WebExtensionDeclarativeNetRequestSQLiteStore::addRules
both captured Ref<JSON::Value> into lambdas dispatched to a background
WorkQueue, while the main
thread still held live references to the same objects. Concurrent increments
and decrements from the
two threads cause a lost update on the m_refCount. When the object is freed
prematurely on the main
thread, the WorkQueue is left holding with a dangling reference, causing a
heap-use-after-free on
the WorkQueue.
Fix this by serializing the data before dispatching it to the WorkQueue.
* Source/WebKit/Shared/Extensions/WebExtensionRegisteredScriptsSQLiteStore.cpp:
(WebKit::WebExtensionRegisteredScriptsSQLiteStore::addScripts):
(WebKit::WebExtensionRegisteredScriptsSQLiteStore::insertScript):
* Source/WebKit/Shared/Extensions/WebExtensionRegisteredScriptsSQLiteStore.h:
*
Source/WebKit/UIProcess/Extensions/WebExtensionDeclarativeNetRequestSQLiteStore.cpp:
(WebKit::WebExtensionDeclarativeNetRequestSQLiteStore::addRules):
(WebKit::WebExtensionDeclarativeNetRequestSQLiteStore::insertRule):
*
Source/WebKit/UIProcess/Extensions/WebExtensionDeclarativeNetRequestSQLiteStore.h:
Identifier: 305413.675@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.827@webkitglib/2.52
Commit: adfe8abddbda0c7889f1db74b953afdfabddbb26
https://github.com/WebKit/WebKit/commit/adfe8abddbda0c7889f1db74b953afdfabddbb26
Author: Chris Dumez <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
M Source/WTF/wtf/Ref.h
M Source/WTF/wtf/RefPtr.h
M Source/WTF/wtf/WeakPtr.h
M Source/WebCore/Modules/indexeddb/client/IDBConnectionToServer.h
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteAdapter.h
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteBindGroup.h
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteCommandEncoder.h
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteCompositorIntegration.h
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteComputePassEncoder.cpp
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteComputePipeline.h
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteDevice.cpp
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteDevice.h
M Source/WebKit/GPUProcess/graphics/WebGPU/RemotePresentationContext.cpp
M Source/WebKit/GPUProcess/graphics/WebGPU/RemotePresentationContext.h
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteQueue.cpp
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteRenderBundleEncoder.cpp
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteRenderBundleEncoder.h
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteRenderPassEncoder.cpp
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteRenderPassEncoder.h
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteRenderPipeline.h
M Source/WebKit/GPUProcess/graphics/WebGPU/RemoteShaderModule.h
M Source/WebKit/Platform/cocoa/PaymentAuthorizationPresenter.h
M Source/WebKit/Shared/WebBackForwardListFrameItem.h
M Source/WebKit/UIProcess/Extensions/WebExtensionController.h
M Source/WebKit/UIProcess/Inspector/WebInspectorUIProxy.h
M Source/WebKit/UIProcess/RemotePageVisitedLinkStoreRegistration.h
M Source/WebKit/UIProcess/WebFrameProxy.h
M Source/WebKit/WebProcess/WebPage/DrawingArea.h
Log Message:
-----------
Cherry-pick 305907@main (0a2324667740).
https://bugs.webkit.org/show_bug.cgi?id=305822
Allow constructing a Ref / RefPtr from a WeakRef / WeakPtr
https://bugs.webkit.org/show_bug.cgi?id=305822
Reviewed by Anne van Kesteren.
Allow constructing a Ref / RefPtr from a WeakRef / WeakPtr, without
requiring calling `.get()`. Also allow silencing converting a WeakPtr<T>
to a T* for consistency with other smart pointer types.
Also simplify code in Source/WebKit/ as a result. If this is approved,
I'll simplify the rest of the codebase.
* Source/WTF/wtf/Ref.h:
* Source/WTF/wtf/RefPtr.h:
* Source/WTF/wtf/WeakPtr.h:
(WTF::WeakPtr::operator T* const):
* Source/WebCore/Modules/indexeddb/client/IDBConnectionToServer.h:
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteAdapter.h:
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteBindGroup.h:
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteCommandEncoder.h:
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteCompositorIntegration.h:
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteComputePassEncoder.cpp:
(WebKit::RemoteComputePassEncoder::protectedObjectHeap const):
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteComputePipeline.h:
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteDevice.cpp:
(WebKit::RemoteDevice::protectedObjectHeap const):
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteDevice.h:
* Source/WebKit/GPUProcess/graphics/WebGPU/RemotePresentationContext.cpp:
(WebKit::RemotePresentationContext::protectedObjectHeap const):
* Source/WebKit/GPUProcess/graphics/WebGPU/RemotePresentationContext.h:
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteQueue.cpp:
(WebKit::RemoteQueue::protectedObjectHeap const):
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteRenderBundleEncoder.cpp:
(WebKit::RemoteRenderBundleEncoder::protectedObjectHeap const):
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteRenderBundleEncoder.h:
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteRenderPassEncoder.cpp:
(WebKit::RemoteRenderPassEncoder::protectedObjectHeap const):
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteRenderPassEncoder.h:
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteRenderPipeline.h:
* Source/WebKit/GPUProcess/graphics/WebGPU/RemoteShaderModule.h:
* Source/WebKit/Platform/cocoa/PaymentAuthorizationPresenter.h:
(WebKit::PaymentAuthorizationPresenter::client):
(WebKit::PaymentAuthorizationPresenter::protectedClient):
* Source/WebKit/Shared/WebBackForwardListFrameItem.h:
(WebKit::WebBackForwardListFrameItem::parent const):
(WebKit::WebBackForwardListFrameItem::protectedParent const):
* Source/WebKit/UIProcess/Extensions/WebExtensionController.h:
* Source/WebKit/UIProcess/Inspector/WebInspectorUIProxy.h:
(WebKit::WebInspectorUIProxy::inspectedPage const):
(WebKit::WebInspectorUIProxy::protectedInspectedPage const):
(WebKit::WebInspectorUIProxy::inspectorPage const):
(WebKit::WebInspectorUIProxy::protectedInspectorPage const):
* Source/WebKit/UIProcess/RemotePageVisitedLinkStoreRegistration.h:
(WebKit::RemotePageVisitedLinkStoreRegistration::~RemotePageVisitedLinkStoreRegistration):
* Source/WebKit/UIProcess/WebFrameProxy.h:
(WebKit::WebFrameProxy::parentFrame const):
(WebKit::WebFrameProxy::opener const):
(WebKit::WebFrameProxy::disownedOpener const):
* Source/WebKit/WebProcess/WebPage/DrawingArea.h:
(WebKit::DrawingArea::send):
(WebKit::DrawingArea::protectedWebPage const):
Canonical link: https://commits.webkit.org/305877.828@webkitglib/2.52
Commit: a7a45186ece2fda8ef5e8a8a0918febb8c6b416e
https://github.com/WebKit/WebKit/commit/a7a45186ece2fda8ef5e8a8a0918febb8c6b416e
Author: Chris Dumez <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
A LayoutTests/workers/permissions-query-crash-expected.txt
A LayoutTests/workers/permissions-query-crash.html
M Source/WebCore/Modules/permissions/Permissions.cpp
M Source/WebCore/Modules/permissions/Permissions.h
Log Message:
-----------
Cherry-pick f7d3c0785bb0. https://bugs.webkit.org/show_bug.cgi?id=312459
UAF in WebContent due to Cross-thread destruction race of worker
DeferredPromise via Permissions::query() + worker.terminate()
https://bugs.webkit.org/show_bug.cgi?id=312459
rdar://174651133
Reviewed by Ryosuke Niwa.
When Permissions::query() is called in a worker, we would dispatch a lambda
to the main thread, get the information and then try to go back to the
worker thread using ScriptExecutionContext::postTaskTo() in order to
call the promise with the result. However, in case of worker termination,
ScriptExecutionContext::postTaskTo() would fail and the lambda would get
destroyed on the main thread, without getting called. This would lead to
a security bug because the lambda was capturing the promise object which
is a worker object and thus should not get destroyed on the main thread.
To address the issue, we now store the promise in a HashMap on the
Permissions object. We then capture a promise identifier in the lambda
instead of the promise. In the ~Permissions() destructor, if there are
pending promises, we reject them.
I made the following changes also:
1. I used `Ref<DeferredPromise>` type for the promise instead of
`DOMPromiseDeferred<IDLInterface<PermissionStatus>>` so that I could
store the promise in a HashMap.
2. There was a LOT of code duplication in Permissions::query() for the
main thread code path and the worker code path. I merged them so we
now have a single code path for both. This simplifies things a lot.
Test: workers/permissions-query-crash.html
* LayoutTests/workers/permissions-query-crash-expected.txt: Added.
* LayoutTests/workers/permissions-query-crash.html: Added.
* Source/WebCore/Modules/permissions/Permissions.cpp:
(WebCore::determineGeolocationPermissionState):
(WebCore::Permissions::~Permissions):
(WebCore::processPermissionQueryResult):
(WebCore::Permissions::query):
* Source/WebCore/Modules/permissions/Permissions.h:
Identifier: 305413.686@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.829@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/e5b8f463a4a9...a7a45186ece2
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
