Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: d58336d7c3c6f602b345e126474dee8143f0b9f7
https://github.com/WebKit/WebKit/commit/d58336d7c3c6f602b345e126474dee8143f0b9f7
Author: Chris Dumez <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A LayoutTests/ipc/networkstoragemanager-putoradd-nullptr-key-expected.txt
A LayoutTests/ipc/networkstoragemanager-putoradd-nullptr-key.html
M Source/WebCore/Modules/indexeddb/IDBKeyData.h
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp
Log Message:
-----------
Cherry-pick 7cf0b2823ce9. https://bugs.webkit.org/show_bug.cgi?id=314538
[IndexedDB] IDBKeyData validation on CoreIPC should reject invalid key types
https://bugs.webkit.org/show_bug.cgi?id=314538
rdar://174499511
Reviewed by Sihui Liu.
IDBKeyData implements CustomHashTraits, and IDBKeyDataHashTraits uses the
std::nullptr_t variant (IDBKeyData::isNull()) as the HashMap empty value.
A compromised WebContent process can send PutOrAdd with an IDBKeyData
whose variant is std::nullptr_t; the message passes IPC decoding and
reaches MemoryObjectStore::addRecord, which inserts the key into
m_keyValueStore — a HashMap whose empty sentinel is exactly that value —
crashing the Network process via the HashMap key validation RELEASE_ASSERT.
The IDBKeyData::Invalid variant is similarly unusable as a HashMap key.
Add a MESSAGE_CHECK at the putOrAdd handler that keyData is either a
placeholder or a valid key. IDBTransaction::putOrAdd sends a placeholder
(nullptr_t + isPlaceholder=true) for auto-generated keys, which is
replaced with the generated key on the server side before any HashMap
insertion, so placeholders are exempt. The check cannot be hoisted into
the IDBKeyData IPC validator because std::nullptr_t and Invalid variants
have legitimate non-placeholder IPC uses (e.g. IDBCursor::advance sends
a null IDBKeyData as the "no search key" sentinel; Invalid IDBKeyData
can come from detached-ArrayBuffer index keys in multi-entry indexes).
Test: ipc/networkstoragemanager-putoradd-nullptr-key.html
* Source/WebCore/Modules/indexeddb/IDBKeyData.h:
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
(WebKit::NetworkStorageManager::putOrAdd):
Identifier: 305413.887@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.921@webkitglib/2.52
Commit: 0099dea1a9d544eeffd377f0cf8086c0e2b9852a
https://github.com/WebKit/WebKit/commit/0099dea1a9d544eeffd377f0cf8086c0e2b9852a
Author: Rupin Mittal <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
M LayoutTests/ipc/coreipc.js
A LayoutTests/ipc/loadping-firstpartyforcookies-message-check-expected.txt
A LayoutTests/ipc/loadping-firstpartyforcookies-message-check.html
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
Cherry-pick fd5906672902. https://bugs.webkit.org/show_bug.cgi?id=313496
Missing allowsFirstPartyForCookies check in loadPing() IPC may lead to
cross-origin cookie access
https://bugs.webkit.org/show_bug.cgi?id=313496
rdar://174708224
Reviewed by Charlie Wolfe and Sihui Liu.
A web process could send an IPC message containing a cross-site origin and
loadPing() would then send the request to the cross-site origin which would
respond with its cookies.
To prevent this, add a MESSAGE_CHECK in loadPing() which will check if the
web process has first party cookie access to the origin in the request and
terminate the web process if not.
New layout test confirms that we hit the message check:
loadping-firstpartyforcookies-message-check.html
* LayoutTests/ipc/coreipc.js:
(export.ArgumentSerializer):
* LayoutTests/ipc/loadping-firstpartyforcookies-message-check-expected.txt:
Added.
* LayoutTests/ipc/loadping-firstpartyforcookies-message-check.html: Added.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::loadPing):
Identifier: 305413.799@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.922@webkitglib/2.52
Commit: 0fbfd7f3a225e8be76692e4f31f66ae48cec89f3
https://github.com/WebKit/WebKit/commit/0fbfd7f3a225e8be76692e4f31f66ae48cec89f3
Author: Chris Dumez <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A
LayoutTests/http/tests/ipc/webpageproxy-didfailload-failingurl-message-check-expected.txt
A
LayoutTests/http/tests/ipc/webpageproxy-didfailload-failingurl-message-check.html
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick e6341887dd92. https://bugs.webkit.org/show_bug.cgi?id=314873
[WebKit Process Model] missing MESSAGE_CHECK_URL on error.failingURL() in
WebPageProxy::didFailLoadForFrame
https://bugs.webkit.org/show_bug.cgi?id=314873
rdar://176912820
Reviewed by Ryosuke Niwa.
WebPageProxy::didFailLoadForFrame accepts a WebCore::ResourceError from the
WebContent
process and forwards it to the embedding client without validating
error.failingURL()
against the sending process's allowed URL set. The sibling handler
didFailProvisionalLoadForFrameShared already performs this check. On iOS,
MobileSafari
feeds the unchecked failingURL back into
`-[WKWebView _loadAlternateHTMLString:baseURL:forUnreachableURL:]`, which causes
WebPageProxy::loadAlternateHTML to grant the sending WebContent process read
access to
an attacker-chosen file:// directory in both the UI process and the Network
process.
Add MESSAGE_CHECK_URL(process, error.failingURL()) to
WebPageProxy::didFailLoadForFrame,
mirroring didFailProvisionalLoadForFrameShared, so a compromised WebContent
process that
forges a file:// failingURL is terminated before the error reaches the
navigation client.
Test: http/tests/ipc/webpageproxy-didfailload-failingurl-message-check.html
*
LayoutTests/http/tests/ipc/webpageproxy-didfailload-failingurl-message-check-expected.txt:
Added.
*
LayoutTests/http/tests/ipc/webpageproxy-didfailload-failingurl-message-check.html:
Added.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::didFailLoadForFrame):
Identifier: 305413.916@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.923@webkitglib/2.52
Commit: 504dca28c3a634003604953d0956cc061ddc0e19
https://github.com/WebKit/WebKit/commit/504dca28c3a634003604953d0956cc061ddc0e19
Author: Rupin Mittal <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
Cherry-pick 32b29db38205. https://bugs.webkit.org/show_bug.cgi?id=314149
Unvalidated replacementPath in
NetworkConnectionToWebProcess::registerInternalFileBlobURL() could lead to
wrongful file deletion
https://bugs.webkit.org/show_bug.cgi?id=314149
rdar://175677292
Reviewed by Brady Eidson and Per Arne Vollan.
NetworkConnectionToWebProcess::registerInternalFileBlobURL() takes in a a file
path called replacementPath and a SandboxExtensionHandle. If the web process
sends an empty handle, then the only validation done on replacementPath is
isFilePathAllowed(), which may be too permissive. Later on, the web process
could
send the IPC NetworkConnectionToWebProcess::unregisterBlobURL() with a null
topOrigin, which kicks off this chain: BlobData destroyed, BlobDataFileReference
destroyed, FileSystem::deleteFile(m_replacementPath) which deleted the file at
the replacementPath that was passed in.
This may allow the web process to delete a file that it shouldn't be able to.
To prevent this, we add a message check which confirms that if the web process
would like to use the file at the replacementPath it specifies, it must have
a sandbox extension allowing it to do so. Otherwise, the web process will be
terminated.
We also add a fixme comment to note that in the future, we should look into
ensuring that the web process does not send file paths to the network process
at all.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::registerInternalFileBlobURL):
Identifier: 305413.843@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.924@webkitglib/2.52
Commit: e4fafe71e9822160a3e9394d54babb777a8f5438
https://github.com/WebKit/WebKit/commit/e4fafe71e9822160a3e9394d54babb777a8f5438
Author: Chris Dumez <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
M Source/WebCore/loader/DocumentLoader.cpp
M Source/WebKit/UIProcess/API/APINavigation.h
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick 8aeb259135a8. https://bugs.webkit.org/show_bug.cgi?id=315004
Compromised Web Content can use a navigation-response Download policy on a
data: URL to write attacker-controlled bytes to disk
https://bugs.webkit.org/show_bug.cgi?id=315004
rdar://177019828
Reviewed by Basuke Suzuki.
A compromised Web Content process can cause the UI process to write
attacker-chosen
bytes to ~/Downloads/Unknown with no user interaction, no `download` attribute,
and
no Content-Disposition header. The renderer opens a popup navigation to a
data:application/octet-stream;base64,<payload> URL; because the MIME type is not
showable, the navigation delegate's stock policy returns
WKNavigationResponsePolicyDownload.
WebPageProxy::receivedNavigationResponsePolicyDecision
unconditionally mints a real DownloadProxy for the data: URL, the natural
WebFrame::startDownload -> NetworkConnectionToWebProcess::StartDownload flow
runs,
and the data: URL bytes land on disk. The renderer-supplied user-gesture token
is
forged to bypass the popup blocker; everything downstream is stock behavior.
Refuse PolicyAction::Download for data: URLs in
WebPageProxy::receivedNavigationResponsePolicyDecision unless the navigation was
driven by the API client. The carve-out uses
Navigation::m_requestIsFromClientInput
(set only by UIProcess paths such as -loadRequest:), not the renderer-supplied
isRequestFromClientOrUserInput flag. Legitimate data: URL downloads via
<a href="data:..." download> use the navigation-action policy, and explicit
downloads
via -[WKWebView startDownloadUsingRequest:] use a separate API path -- neither
reaches receivedNavigationResponsePolicyDecision.
As defense in depth, also extend the existing disallowDataRequest() check in
DocumentLoader::continueAfterContentPolicy to the PolicyAction::Download branch
so
the same restriction that already applies to PolicyAction::Use applies to
downloads.
The Web Content process is the compromised party in this report, so this is not
the
primary defense, but it keeps non-Cocoa ports and future flows consistent.
* Source/WebCore/loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::continueAfterContentPolicy):
* Source/WebKit/UIProcess/API/APINavigation.h:
(API::Navigation::isFromAPIClientRequest const):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::receivedNavigationResponsePolicyDecision):
Identifier: 305413.929@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.925@webkitglib/2.52
Commit: 161e3de880ab752cf1e39b53103db8accfcacec6
https://github.com/WebKit/WebKit/commit/161e3de880ab752cf1e39b53103db8accfcacec6
Author: Chris Dumez <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A
LayoutTests/http/tests/ipc/createnewpage-file-body-sandbox-extension-expected.txt
A LayoutTests/http/tests/ipc/createnewpage-file-body-sandbox-extension.html
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick 77fa86c2ea4d. https://bugs.webkit.org/show_bug.cgi?id=315167
[WebKit Process Model] WebPageProxy::createNewPage missing
hasGrantedSandboxExtensionForFile check on NavigationActionData.request httpBody
https://bugs.webkit.org/show_bug.cgi?id=315167
rdar://177367508
Reviewed by Per Arne Vollan.
A compromised WebContent process can send WebPageProxy::CreateNewPage with
an arbitrary file path in the request body's EncodedFileData. When the UI
process re-emits that request via loadRequest(), encoding the
LoadParameters runs FormDataReference::sandboxExtensionHandles() in the UI
process, which calls SandboxExtension::createHandle() on the
attacker-supplied path and serializes a live com.apple.app-sandbox.read
token to a WebContent process — a full sandbox escape to arbitrary host
filesystem read.
Add a MESSAGE_CHECK_COMPLETION at the top of createNewPage() that calls
WebProcessProxy::hasGrantedSandboxExtensionForFile() on every
EncodedFileData filename in the request body, rejecting any path the
sending WebContent process was never granted access to. This mirrors the
equivalent check rdar://174662982 added to decidePolicyForNavigationAction().
Test: http/tests/ipc/createnewpage-file-body-sandbox-extension.html
*
LayoutTests/http/tests/ipc/createnewpage-file-body-sandbox-extension-expected.txt:
Added.
* LayoutTests/http/tests/ipc/createnewpage-file-body-sandbox-extension.html:
Added.
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::createNewPage):
Identifier: 305413.942@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.926@webkitglib/2.52
Commit: 2d5dfaaef18f9cfff592c85909df213dc187fbae
https://github.com/WebKit/WebKit/commit/2d5dfaaef18f9cfff592c85909df213dc187fbae
Author: Ryosuke Niwa <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A
LayoutTests/fast/forms/auto-fill-button/auto-fill-button-click-then-type-change-crash-expected.txt
A
LayoutTests/fast/forms/auto-fill-button/auto-fill-button-click-then-type-change-crash.html
M Source/WebCore/html/TextFieldInputType.cpp
M Source/WebCore/html/TextFieldInputType.h
M Source/WebCore/html/shadow/AutoFillButtonElement.cpp
M Source/WebCore/html/shadow/AutoFillButtonElement.h
Log Message:
-----------
Cherry-pick 354642cc1251. https://bugs.webkit.org/show_bug.cgi?id=313700
Use-after-free in AutoFillButtonElement::defaultEventHandler
https://bugs.webkit.org/show_bug.cgi?id=313700
Reviewed by Aditya Keerthi.
AutoFillButtonElement held its AutoFillButtonOwner as a raw C++ reference. When
a click listener on the host
input element flips input.type in the middle of a click event dispatch,
HTMLInputElement::updateType()
destroys the old TextFieldInputType (the only owner), but the button is kept
alive by EventPath.
callDefaultEventHandlersInBubblingOrder then makes the virtual call
m_owner.autoFillButtonElementWasClicked()
through freed memory.
Fix mirrors the existing SpinButtonElement pattern: AutoFillButtonOwner now
derives from
AbstractRefCountedAndCanMakeWeakPtr, the back-reference is a WeakPtr that is
null-checked (and RefPtr-protected)
in defaultEventHandler, TextFieldInputType forwards ref()/deref() to InputType
and clears the back-reference
in removeShadowSubtree() via a new removeAutoFillButtonOwner().
Test:
fast/forms/auto-fill-button/auto-fill-button-click-then-type-change-crash.html
*
LayoutTests/fast/forms/auto-fill-button/auto-fill-button-click-then-type-change-crash-expected.txt:
Added.
*
LayoutTests/fast/forms/auto-fill-button/auto-fill-button-click-then-type-change-crash.html:
Added.
* Source/WebCore/html/TextFieldInputType.cpp:
(WebCore::TextFieldInputType::removeShadowSubtree):
* Source/WebCore/html/TextFieldInputType.h:
* Source/WebCore/html/shadow/AutoFillButtonElement.cpp:
(WebCore::AutoFillButtonElement::defaultEventHandler):
* Source/WebCore/html/shadow/AutoFillButtonElement.h:
Identifier: 305413.807@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.927@webkitglib/2.52
Commit: e4e9c9ff52b1bb4e9b9d4a6bbc40e5cdee6a6e11
https://github.com/WebKit/WebKit/commit/e4e9c9ff52b1bb4e9b9d4a6bbc40e5cdee6a6e11
Author: Charlie Wolfe <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A
LayoutTests/http/tests/storageAccess/request-storage-access-rejected-without-gesture-should-not-activate-expected.txt
A
LayoutTests/http/tests/storageAccess/request-storage-access-rejected-without-gesture-should-not-activate.html
A
LayoutTests/http/tests/storageAccess/resources/request-storage-access-without-gesture-check-activation-iframe.html
M Source/WebCore/dom/DocumentStorageAccess.cpp
M Source/WebCore/dom/DocumentStorageAccess.h
M Source/WebCore/page/ChromeClient.h
M Source/WebKit/NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp
M Source/WebKit/NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in
M Source/WebKit/Scripts/webkit/messages.py
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
Log Message:
-----------
Cherry-pick 6fae18f756d2. https://bugs.webkit.org/show_bug.cgi?id=313478
Reject requestStorageAccess() without gesture should not synthesize user
activation
https://bugs.webkit.org/show_bug.cgi?id=313478
rdar://174964081
Reviewed by Matthew Finkel.
The completion handler for requestStorageAccess() preserved the user gesture
whenever the prompt was
not shown, including on the no-gesture fast-reject path. This synthesized a
UserGestureIndicator
from nothing, allowing the .catch handler to call gesture-gated APIs from a
cross-site iframe with
zero user interaction.
Gate gesture preservation on a real gesture having existed at call time.
Test:
http/tests/storageAccess/request-storage-access-rejected-without-gesture-should-not-activate.html
*
LayoutTests/http/tests/storageAccess/request-storage-access-rejected-without-gesture-should-not-activate-expected.txt:
Added.
*
LayoutTests/http/tests/storageAccess/request-storage-access-rejected-without-gesture-should-not-activate.html:
Added.
*
LayoutTests/http/tests/storageAccess/resources/request-storage-access-without-gesture-check-activation-iframe.html:
Added.
* Source/WebCore/dom/DocumentStorageAccess.cpp:
(WebCore::DocumentStorageAccess::requestStorageAccess):
(WebCore::DocumentStorageAccess::requestStorageAccessQuirk):
* Source/WebCore/dom/DocumentStorageAccess.h:
* Source/WebCore/page/ChromeClient.h:
(WebCore::ChromeClient::requestStorageAccess):
* Source/WebKit/NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:
(WebKit::WebResourceLoadStatisticsStore::requestStorageAccess):
* Source/WebKit/NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h:
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::requestStorageAccess):
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h:
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in:
* Source/WebKit/Scripts/webkit/messages.py:
(headers_for_type):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp:
(WebKit::WebChromeClient::requestStorageAccess):
* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::requestStorageAccess):
* Source/WebKit/WebProcess/WebPage/WebPage.h:
Identifier: 305413.854@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.928@webkitglib/2.52
Commit: 5ea23180cb2dcea0d1df459014cada037dea3349
https://github.com/WebKit/WebKit/commit/5ea23180cb2dcea0d1df459014cada037dea3349
Author: Keith Miller <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A JSTests/stress/wasm-compile-stale-ticket.js
M Source/JavaScriptCore/CMakeLists.txt
M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj
M Source/JavaScriptCore/jsc.cpp
M Source/JavaScriptCore/runtime/DeferredWorkTimer.cpp
M Source/JavaScriptCore/runtime/DeferredWorkTimer.h
R Source/JavaScriptCore/runtime/DeferredWorkTimerInlines.h
M Source/JavaScriptCore/runtime/JSFinalizationRegistry.cpp
M Source/JavaScriptCore/runtime/JSGlobalObject.cpp
M Source/JavaScriptCore/runtime/JSGlobalObject.h
M Source/JavaScriptCore/runtime/WaiterListManager.cpp
M Source/JavaScriptCore/runtime/WaiterListManager.h
M Source/JavaScriptCore/wasm/WasmStreamingCompiler.cpp
M Source/JavaScriptCore/wasm/WasmStreamingCompiler.h
M Source/JavaScriptCore/wasm/js/JSWebAssembly.cpp
Log Message:
-----------
Cherry-pick 824ba19ea552. https://bugs.webkit.org/show_bug.cgi?id=314671
[JSC] DeferredWorkTimer should vend Weak references to Tickets
https://bugs.webkit.org/show_bug.cgi?id=314671
rdar://176445072
Reviewed by Yijia Huang.
DeferredWorkTimer::addPendingWork returned a raw Ticket (alias for TicketData*),
and callers routinely captured that raw pointer into SharedTask lambdas that
run on background threads (Wasm worklist, etc.). If the associated
JSGlobalObject died before the background work completed, the GC End phase
cancelled the ticket, doWork() removed the cancelled entry from
m_pendingTickets, and the last Ref<TicketData> dropped — freeing the slot. The
background thread then dereferenced the dangling pointer in
scheduleWorkSoon(stalePtr, ...). Because the TZone allocator reuses freed
slots, m_pendingTickets.find(stalePtr) could match a fresh ticket at the same
address, running the stale callback against the wrong target and tripping a
jsCast / JSPromise::flags assertion in doWork.
0e0b5050 fixed WasmStreamingCompiler for this pattern by storing
ThreadSafeWeakPtr<TicketData> and promote-and-checking at every use site.
This patch moves the safety requirement into the API so future callers can't
regress:
1. Rename DeferredWorkTimer::TicketData to DeferredWorkTimer::Ticket and
remove the old `using Ticket = TicketData*` alias.
2. Add `using WeakTicket = ThreadSafeWeakPtr<Ticket>`. addPendingWork now
returns WeakTicket.
3. Replace scheduleWorkSoon(Ticket, Task&&) with the new
scheduleWorkSoonIfActive(const WeakTicket&, Task&&) which internally
promotes the weak ticket, drops the request if it's gone or cancelled,
and returns whether it was queued. This is the only way to enqueue work,
so callers cannot forget the liveness check.
4. Change m_tasks from Deque<std::tuple<Ticket, Task>> to
Deque<std::tuple<Ref<Ticket>, Task>> so queued work keeps the ticket
alive until doWork() runs, closing the slot-reuse window the repro
exploits.
5. hasPendingWork, hasDependencyInPendingWork, cancelPendingWork take
Ticket& so callers already holding a RefPtr can't accidentally pass a
null / raw pointer across an async boundary.
6. Task signature is Function<void(Ticket&)>; doWork dereferences the
stored Ref when dispatching.
Call-site cleanups:
* jsc.cpp functionSetTimeout — no more manual promote/check; the dispatch
lambda just forwards the WeakTicket into scheduleWorkSoonIfActive.
* WasmStreamingCompiler — m_ticket becomes ThreadSafeWeakPtr<Ticket>; the
destructor, didComplete, fail, and cancel paths use the new API.
* JSWebAssembly.cpp webAssemblyModuleValidateAsync / instantiate /
compileAndInstantiate — three shared-task lambdas that previously
captured raw ticket / globalObject / promise pointers now capture a
WeakTicket, recover promise / globalObject / dependencies from
Ticket::target() and Ticket::dependencies() inside the scheduled task,
and let scheduleWorkSoonIfActive handle liveness.
* WaiterListManager — m_ticket type rename; scheduleWorkAndClear collapses
to a single scheduleWorkSoonIfActive that clears on success.
* JSFinalizationRegistry — synchronous path uses scheduleWorkSoonIfActive
and RELEASE_ASSERTs the return to match the existing contract.
The now-empty DeferredWorkTimerInlines.h is removed.
Test: JSTests/stress/wasm-compile-stale-ticket.js
Identifier: 305413.892@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.929@webkitglib/2.52
Commit: 1908f9a087a859daa60d2fab79971f660f55991a
https://github.com/WebKit/WebKit/commit/1908f9a087a859daa60d2fab79971f660f55991a
Author: Chris Dumez <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A
LayoutTests/http/tests/site-isolation/find-string-with-cross-page-focused-frame-crash-expected.txt
A
LayoutTests/http/tests/site-isolation/find-string-with-cross-page-focused-frame-crash.html
M Source/WTF/wtf/ListHashSet.h
M Source/WebKit/UIProcess/WebFrameProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
Log Message:
-----------
Cherry-pick 7b5d09d5675a. https://bugs.webkit.org/show_bug.cgi?id=315348
[WebKit Process Model | All] Wrong-container end() comparison in
WebFrameProxy::nextSibling/previousSibling
https://bugs.webkit.org/show_bug.cgi?id=315348
rdar://176891673
Reviewed by Ryosuke Niwa.
WebFrameProxy::nextSibling() and previousSibling() obtain an iterator from
m_parentFrame->m_childFrames.find(this) but compare it against this frame's own
m_childFrames.end(). ListHashSet const_iterator equality compares only
m_position,
so the not-found guard is structurally always false in Release. They also call
last()/first() on the parent's m_childFrames without checking isEmpty(), which
dereferences the sentinel of an empty list.
A child can have a non-null m_parentFrame whose m_childFrames no longer contains
it because webProcessWillShutDown() and removeChildFrames() drop the parent's
child set without nulling each child's m_parentFrame. A compromised WebContent
process can keep such a frame alive across pages because focusedFrameChanged()
does not verify that the looked-up frame belongs to this page before storing it
in m_focusedFrame. Under Site Isolation, FindStringCallbackAggregator's
destructor
then traverses from focusedOrMainFrame() through nextSibling() on the orphaned
child, advances past the parent's sentinel, and returns &parent.m_parentFrame's
WeakPtr impl typed as WebFrameProxy*, leading to an EXC_ARM_PAC_FAIL in CFRetain
in the UI process.
Fix all four sites: compare against the parent's end(), early-return when the
parent's child set is empty, null each child's m_parentFrame when emptying
m_childFrames in webProcessWillShutDown() and removeChildFrames(), and
MESSAGE_CHECK in focusedFrameChanged() that the frame belongs to this page.
Also do hardening in ListHashSet so that calling first() / last() on an
empty set crashes safely.
Test:
http/tests/site-isolation/find-string-with-cross-page-focused-frame-crash.html
*
LayoutTests/http/tests/site-isolation/find-string-with-cross-page-focused-frame-crash-expected.txt:
Added.
*
LayoutTests/http/tests/site-isolation/find-string-with-cross-page-focused-frame-crash.html:
Added.
* Source/WTF/wtf/ListHashSet.h:
(WTF::U>::first):
(WTF::U>::first const):
(WTF::U>::last):
(WTF::U>::last const):
* Source/WebKit/UIProcess/WebFrameProxy.cpp:
(WebKit::WebFrameProxy::webProcessWillShutDown):
(WebKit::WebFrameProxy::removeChildFrames):
(WebKit::WebFrameProxy::nextSibling const):
(WebKit::WebFrameProxy::previousSibling const):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::focusedFrameChanged):
Identifier: 305413.957@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.930@webkitglib/2.52
Commit: 6b0832a5592a8e1d4046b9bf7db40bdec2e1cd61
https://github.com/WebKit/WebKit/commit/6b0832a5592a8e1d4046b9bf7db40bdec2e1cd61
Author: Youenn Fablet <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A
LayoutTests/http/tests/workers/service/resources/service-worker-download-task-uaf-worker.js
A
LayoutTests/http/tests/workers/service/service-worker-download-task-uaf.https-expected.txt
A
LayoutTests/http/tests/workers/service/service-worker-download-task-uaf.https.html
M Source/WebCore/workers/service/server/SWServer.h
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
Cherry-pick e4baf2c41a05. https://bugs.webkit.org/show_bug.cgi?id=315348
[WebKit] Use-after-free in ServiceWorkerDownloadTask via stale
FunctionDispatcherQueue after second EstablishSWContextConnection
rdar://176481482
Reviewed by Chris Dumez.
WebContent process could at any time try to establish a new service worker
context connection.
In that case, NetworkConnectionToWebProcess would destroy any existing service
worker context connection without closing it.
While this should not happen in practice, a compromised WebContent process can
trigger this code path.
To prevent this, NetworkConnectionToWebProcess is now message checking whether
service worker has a pending connection for that domain.
This prevents logic failures further in networking process and UI process which
might not expect the creation of a new connection.
As a further defense, we are closing any existing service worker context
connection that is pre-existing.
A future patch should MESSAGE_CHECK that there is no pre-existing service
worker context connection.
Test: http/tests/workers/service/service-worker-download-task-uaf.https.html
*
LayoutTests/http/tests/workers/service/resources/service-worker-download-task-uaf-worker.js:
Added.
(event.const.stream.new.ReadableStream.start):
*
LayoutTests/http/tests/workers/service/service-worker-download-task-uaf.https-expected.txt:
Added.
*
LayoutTests/http/tests/workers/service/service-worker-download-task-uaf.https.html:
Added.
* Source/WebCore/workers/service/server/SWServer.h:
(WebCore::SWServer::hasPendingConnectionDomain const):
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::establishSWContextConnection):
(WebKit::NetworkConnectionToWebProcess::serviceWorkerServerToContextConnectionNoLongerNeeded):
Identifier: 305413.893@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.931@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/945c4ba743c1...6b0832a5592a
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
