Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: be936366954ae571e3e05653255b58e6615d474a
https://github.com/WebKit/WebKit/commit/be936366954ae571e3e05653255b58e6615d474a
Author: Chris Dumez <[email protected]>
Date: 2026-08-07 (Fri, 07 Aug 2026)
Changed paths:
A
LayoutTests/fast/shadow-dom/manual-slot-assign-renderer-teardown-crash-expected.txt
A
LayoutTests/fast/shadow-dom/manual-slot-assign-renderer-teardown-crash.html
M Source/WebCore/dom/SlotAssignment.cpp
Log Message:
-----------
Cherry-pick ddc8b3fae09f. https://bugs.webkit.org/show_bug.cgi?id=317552
UAF in ManualSlotAssignment via WeakHashMap rehash during reentrant
composed-tree teardown
https://bugs.webkit.org/show_bug.cgi?id=REDACTED
rdar://179729192
Reviewed by Anne van Kesteren.
ManualSlotAssignment::slotManualAssignmentDidChange computed
effectiveCurrent
by calling assignedNodesForSlot, which returns a raw pointer to the
cachedAssignment Vector inside a Slot value stored directly in the m_slots
WeakHashMap bucket array. It then called
RenderTreeUpdater::tearDownRenderersAfterSlotChange, whose composed-tree
traversal can call HTMLSlotElement::assignedNodes on a sibling slot and
re-enter ManualSlotAssignment::assignedNodesForSlot. The reentrant
m_slots.ensure call may invoke the WeakHashMap amortized cleanup, sweep
null-keyed entries left by previously inserted, removed and GC-collected
slot
elements, and rehash the table, freeing the bucket array effectiveCurrent
points into. The stale pointer was then dereferenced in
scheduleSlotChangeEventIfNeeded.
Compute effectiveCurrent as a local Vector via effectiveAssignedNodes,
mirroring effectivePrevious, so no pointer into m_slots is held across the
render-tree teardown.
*
LayoutTests/fast/shadow-dom/manual-slot-assign-renderer-teardown-crash-expected.txt:
Added.
*
LayoutTests/fast/shadow-dom/manual-slot-assign-renderer-teardown-crash.html:
Added.
* Source/WebCore/dom/SlotAssignment.cpp:
(WebCore::ManualSlotAssignment::slotManualAssignmentDidChange):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/305877.1058@webkitglib/2.52
Commit: 520c31517003e2fdfa33e01cf9628fda9f4bf01e
https://github.com/WebKit/WebKit/commit/520c31517003e2fdfa33e01cf9628fda9f4bf01e
Author: Charlie Wolfe <[email protected]>
Date: 2026-08-07 (Fri, 07 Aug 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
Cherry-pick 8d9bf389bc0f. https://bugs.webkit.org/show_bug.cgi?id=318244
Validate several ITP and storage access IPC messages
https://bugs.webkit.org/show_bug.cgi?id=318244
rdar://180785498
Reviewed by Matthew Finkel.
This relands the validation that was reverted in rdar://180738421.
Telemetry indicates the
LogUserInteraction MESSAGE_CHECK could rarely fail. It is unclear how this
could happen, so it has
been replaced with an early return and assertion to avoid crashing the
WebContent process.
Test: ipc/forged-resource-load-statistics-storage-access.html
*
LayoutTests/ipc/forged-resource-load-statistics-storage-access-expected.txt:
Added.
* LayoutTests/ipc/forged-resource-load-statistics-storage-access.html:
Added.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::logUserInteraction):
(WebKit::resourceLoadStatisticsContainsOnlyObservableFields):
(WebKit::NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated):
(WebKit::NetworkConnectionToWebProcess::requestStorageAccessUnderOpener):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/305877.1059@webkitglib/2.52
Commit: 9879ca6dcc00d46a565b361623760242f007510f
https://github.com/WebKit/WebKit/commit/9879ca6dcc00d46a565b361623760242f007510f
Author: Rupin Mittal <[email protected]>
Date: 2026-08-07 (Fri, 07 Aug 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
Log Message:
-----------
Cherry-pick 2f80bcf1940f. https://bugs.webkit.org/show_bug.cgi?id=313866
Unreviewed backport.
WebResourceLoader::WillSendRequest reply may lead to cross-origin cookie
access
https://bugs.webkit.org/show_bug.cgi?id=313866
rdar://180785211
Reviewed by Charlie Wolfe.
Consider this sequence of events:
1. A compromised web process schedules a load with its own origin used for
firstPartyForCookies.
2. NetworkConnectionToWebProcess::scheduleResourceLoad() is called and the
message check passes.
3. The request goes through and the server responds with 302 (redirect).
4. NetworkResourceLoader::continueWillSendRedirectedRequest() calls
WebResourceLoader::WillSendRequest() which gives the web process the
chance
to alter the request that will be sent to perform the redirect.
5. The compromised web process alters the request so that
firstPartyForCookies
is now a different origin.
6. NetworkResourceLoader::continueWillSendRequest() receives this altered
request and passes it off to CFNetwork.
7. The result of this request is that the compromised web process receives
the cookies of this different origin.
There are multiple callsites of continueWillSendRequest(), but only one
place
which allows the web process to alter the request before it's given to
continueWillSendRequest(). So we fix this by adding a message check right
before that callsite that will double check that the origin contained in
this
potentially modified request from the web process is in this web process's
allowed list. If not, the web process will be killed so that it doesn't
recieve
the cross-origin cookies.
We also only do this message check if the web process actually changes the
origin. This is because there are cases where the origin is not yet in the
allowlist but not because the web process modified it (like in:
imported/w3c/web-platform-tests/speculation-rules/prefetch/redirect-url.https.html?origin=cross-site-redirect
where there is a cross-site redirect as part of a prefetch, so the
cross-site
origin is supplied by the server but hasn't made it into the allow list
since
the navigation to it is not complete).
When we a previously attempted to add this message check, we found that it
resulted in users hitting the message check in the wild. Based on the fault
logs,
we speculate that the issue could be:
1. A network load is scheduled with the keep alive option.
2. NetworkResourceLoader::continueWillSendRedirectedRequest() sends the IPC
WebResourceLoader::WillSendRequest().
3. Before the web process can respond, it exits. So the web process does not
call the completion handler.
4. The IPC connection between the network and web process is torn down by
Connection::dispatchDidCloseAndInvalidate().
5. This function first calls
NetworkProcessConnectionToWebProcess::didClose()
which keeps the NetworkResourceLoader alive because of the keepalive
option
and removes the web process from m_allowedFirstPartiesForCookies.
6. Then it calls Connection::invalidate() which calls
cancelAsyncReplyHandlers()
which calls the completionHandler with a default constructed
ResourceRequest.
7. In the completionHandler, the NetworkResourceLoader is alive and the
default
constructed request's firstPartyForCookies is empty (which doesn't match
the
likely non-empty stored firstPartyForCookiesFromRedirectRequest), so we
proceed to the check. Since the web process is no longer in
m_allowedFirstPartiesForCookies, allowsFirstPartyForCookies returns
Disallow
and the message check is hit.
So if the completionHandler is called because of the web process exiting
(and
thus the connection being torn down), we early return before doing the
check.
We also early return in the case where WebResourceLoader::willSendRequest()
responds with a default constucted ResourceRequest if there is no
coreLoader.
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::continueWillSendRedirectedRequest):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/[email protected]
Canonical link: https://commits.webkit.org/305877.1060@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/2bc4405358f0...9879ca6dcc00
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
