Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: e93b64e7a179fb348dc71103c93066ff0d07ccb5
https://github.com/WebKit/WebKit/commit/e93b64e7a179fb348dc71103c93066ff0d07ccb5
Author: Said Abou-Hallawa <[email protected]>
Date: 2026-08-05 (Wed, 05 Aug 2026)
Changed paths:
A
LayoutTests/http/tests/canvas/canvas-tainted-image-capture-video-frame-expected.html
A
LayoutTests/http/tests/canvas/canvas-tainted-image-capture-video-frame.html
A
LayoutTests/http/tests/canvas/resources/cross-origin-image-capture-video-frame.html
M Source/WebCore/Modules/mediastream/CanvasCaptureMediaStreamTrack.cpp
Log Message:
-----------
Cherry-pick [email protected] (723dbeacf061).
https://bugs.webkit.org/show_bug.cgi?id=316594
When captured as a video frame, canvas has to be tainted if cross-origin
image are drawn into it
https://bugs.webkit.org/show_bug.cgi?id=316594
rdar://171846032
Reviewed by Simon Fraser.
HTMLCanvasElement::captureStream() allows streaming a canvas's output to a
<video>
element. The track frames of this video is obtained from
CanvasCaptureMediaStreamTrack
::grabFrame(). This function unconditionally gets a VideoFrame by calling
HTMLCanvasElement::toVideoFrame().
If cross-origin images are drawn into the canvas, this canvas has to be
tainted.
So no getImageData() can see the pixels of the cross-origin images.
*
LayoutTests/http/tests/canvas/canvas-tainted-image-capture-video-frame-expected.html:
Added.
*
LayoutTests/http/tests/canvas/canvas-tainted-image-capture-video-frame.html:
Added.
*
LayoutTests/http/tests/canvas/resources/cross-origin-image-capture-video-frame.html:
Added.
* Source/WebCore/Modules/mediastream/CanvasCaptureMediaStreamTrack.cpp:
(WebCore::CanvasCaptureMediaStreamTrack::Source::grabFrame):
(WebCore::CanvasCaptureMediaStreamTrack::Source::captureCanvas):
Identifier: [email protected]
Canonical link:
https://flagged.apple.com:443/proxy?t2=DV9M2o1wG2&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzA1ODc3LjEwNDdAd2Via2l0Z2xpYi8yLjUy&emid=a7631625-ea85-4f5d-ad00-6c0ba34c7439&c=11
Commit: 2f804065261dfd24e934ee5c402b38c6d89a4394
https://github.com/WebKit/WebKit/commit/2f804065261dfd24e934ee5c402b38c6d89a4394
Author: Sihui Liu <[email protected]>
Date: 2026-08-05 (Wed, 05 Aug 2026)
Changed paths:
M Source/WebKit/NetworkProcess/storage/CacheStorageCache.cpp
M Source/WebKit/NetworkProcess/storage/CacheStorageCache.h
M Source/WebKit/NetworkProcess/storage/CacheStorageManager.cpp
M Source/WebKit/NetworkProcess/storage/CacheStorageManager.h
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp
M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h
M
Source/WebKit/NetworkProcess/storage/OriginStorageManager.cpp
Log Message:
-----------
Cherry-pick [email protected] (d4dc872e5bf9).
https://bugs.webkit.org/show_bug.cgi?id=316594
Validate
connection
access
to
DOMCache with DOMCacheIdentifier
rdar://176470206
Reviewed by Chris Dumez.
Many CacheStorage-related messages sent to NetworkStorageManager only
carries DOMCacheIdentifier when asking to operate
on DOMCache storage, and NetworkStorageManager does not check whether the
sender process actually has access to
requested cache. This lets a compromised process forge DOMCacheIdentifier
and access data from other origins. To fix it,
this patch stores the origin in CacheStorageManager and adding an origin
accessor to CacheStorageCache, so that
NetworkStorageManager can run isSiteAllowedForConnection in
CacheStorage-related message handlers.
* Source/WebKit/NetworkProcess/storage/CacheStorageCache.cpp:
(WebKit::CacheStorageCache::origin const):
* Source/WebKit/NetworkProcess/storage/CacheStorageCache.h:
* Source/WebKit/NetworkProcess/storage/CacheStorageManager.cpp:
(WebKit::CacheStorageManager::create):
(WebKit::CacheStorageManager::CacheStorageManager):
* Source/WebKit/NetworkProcess/storage/CacheStorageManager.h:
(WebKit::CacheStorageManager::origin const):
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
(WebKit::NetworkStorageManager::cacheStorageRemoveCache):
(WebKit::NetworkStorageManager::cacheStorageReference):
(WebKit::NetworkStorageManager::cacheStorageRetrieveRecords):
(WebKit::NetworkStorageManager::cacheStorageRemoveRecords):
(WebKit::NetworkStorageManager::cacheStoragePutRecords):
* Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h:
* Source/WebKit/NetworkProcess/storage/OriginStorageManager.cpp:
(WebKit::OriginStorageManager::StorageBucket::cacheStorageManager):
Identifier:
[email protected]
Canonical
link:
https://flagged.apple.com:443/proxy?t2=DT4H5T8lB1&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzA1ODc3LjEwNDhAd2Via2l0Z2xpYi8yLjUy&emid=a7631625-ea85-4f5d-ad00-6c0ba34c7439&c=11
Commit: a806a0e40131d0352261cd7fce4bccae2bcfb3fc
https://github.com/WebKit/WebKit/commit/a806a0e40131d0352261cd7fce4bccae2bcfb3fc
Author: Matthew Finkel <[email protected]>
Date: 2026-08-05 (Wed, 05 Aug 2026)
Changed paths:
A
LayoutTests/http/tests/cookies/same-site/fetch-in-srcdoc-iframe-inside-cross-origin-iframe-expected.txt
A
LayoutTests/http/tests/cookies/same-site/fetch-in-srcdoc-iframe-inside-cross-origin-iframe.html
A
LayoutTests/http/tests/cookies/same-site/img-from-srcdoc-iframe-inside-cross-origin-iframe-expected.txt
A
LayoutTests/http/tests/cookies/same-site/img-from-srcdoc-iframe-inside-cross-origin-iframe.html
A
LayoutTests/http/tests/cookies/same-site/resources/record-image-cookies.py
A
LayoutTests/http/tests/cookies/same-site/resources/srcdoc-creator-img-inside-cross-origin-iframe.html
A
LayoutTests/http/tests/cookies/same-site/resources/srcdoc-creator-inside-cross-origin-iframe.html
M Source/WebCore/loader/FrameLoader.cpp
Log Message:
-----------
Cherry-pick [email protected] (edd74642a6ef).
https://bugs.webkit.org/show_bug.cgi?id=313220
Srcdoc iframes bypass SameSite Strict and Lax cookies
https://bugs.webkit.org/show_bug.cgi?id=313220
rdar://175498842
Reviewed by Charlie Wolfe.
When we set firstPartyForCookies on a subframe, we check if either:
1) shouldInheritSecurityOriginFromOwner is true for the current document's
URL, or
2) if the current document's URL is same-registrable-domain as the
top-level document URL
In the case of an iframe with srcdoc, shouldInheritSecurityOriginFromOwner
returns true (as documented), and this causes us to set the page's mainFrameURL
as
the firstPartyForCookies. We need a conditional exception for
shouldInheritSecurityOriginFromOwner, but it should take nested iframes into
account. This patch adjusts the logic so we inherit the ancestor frame's
siteForCookies instead of the page's URL. The
same-registrable-domain check
remains unchanged.
Test:
http/tests/cookies/same-site/fetch-in-srcdoc-iframe-inside-cross-origin-iframe.html
*
LayoutTests/http/tests/cookies/same-site/fetch-in-srcdoc-iframe-inside-cross-origin-iframe-expected.txt:
Added.
*
LayoutTests/http/tests/cookies/same-site/fetch-in-srcdoc-iframe-inside-cross-origin-iframe.html:
Added.
*
LayoutTests/http/tests/cookies/same-site/img-from-srcdoc-iframe-inside-cross-origin-iframe-expected.txt:
Added.
*
LayoutTests/http/tests/cookies/same-site/img-from-srcdoc-iframe-inside-cross-origin-iframe.html:
Added.
*
LayoutTests/http/tests/cookies/same-site/resources/record-image-cookies.py:
Added.
*
LayoutTests/http/tests/cookies/same-site/resources/srcdoc-creator-img-inside-cross-origin-iframe.html:
Added.
*
LayoutTests/http/tests/cookies/same-site/resources/srcdoc-creator-inside-cross-origin-iframe.html:
Added.
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::setFirstPartyForCookies):
Identifier: [email protected]
Canonical link:
https://flagged.apple.com:443/proxy?t2=Dq7k2Z6tu8&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzA1ODc3LjEwNDlAd2Via2l0Z2xpYi8yLjUy&emid=a7631625-ea85-4f5d-ad00-6c0ba34c7439&c=11
Commit: 1a198b8cacabfd36f55fb6b620df7f2253351610
https://github.com/WebKit/WebKit/commit/1a198b8cacabfd36f55fb6b620df7f2253351610
Author: David Kilzer <[email protected]>
Date: 2026-08-05 (Wed, 05 Aug 2026)
Changed paths:
M Source/WebKit/WebProcess/WebStorage/WebStorageNamespaceProvider.cpp
Log Message:
-----------
Cherry-pick [email protected] (6254fe9499a7).
https://bugs.webkit.org/show_bug.cgi?id=317082
REGRESSION (259876@main): Check for
end
iterator
in
WebStorageNamespaceProvider::decrementUseCount()
<https://bugs.webkit.org/show_bug.cgi?id=317082>
<rdar://179209792>
Reviewed by Zak Ridouh.
Guard against a missing entry before dereferencing the result of
`HashMap::find()` in `decrementUseCount()`. The function relies on
`ASSERT(iterator != ...end())`, which compiles to nothing in release
builds, then reads `iterator->value` unconditionally. When the
identifier is absent, `find()` returns `end()`, and reading
`end()->value` accesses memory one entry past the table's backing
buffer.
The absent-entry case became reachable in 259876@main, which replaced
the page-group-keyed owning map of providers with a single weakly-held
provider (`existingStorageNameSpaceProvider()`). The provider is
now
destroyed when the last page in a Web Content process goes away and
recreated empty for the next page, so a `WebPage` torn down after that
point
decrements
against a provider that never held its identifier.
Return early when the iterator is `end()`, matching the existing guard
in the sibling accessor `sessionStorageNamespace()`. The
`ASSERT(sessionStorageNamespaces.useCount)` is retained so debug builds
still flag a use-count imbalance.
No new tests since this path is reached only during web page teardown
when the session storage namespace entry has already been removed, and
is not directly testable through public API.
* Source/WebKit/WebProcess/WebStorage/WebStorageNamespaceProvider.cpp:
(WebKit::WebStorageNamespaceProvider::decrementUseCount):
Identifier: [email protected]
Canonical link:
https://flagged.apple.com:443/proxy?t2=DJ3b1l1kV9&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzA1ODc3LjEwNTBAd2Via2l0Z2xpYi8yLjUy&emid=a7631625-ea85-4f5d-ad00-6c0ba34c7439&c=11
Commit: 29c97727c5b3f512ab8448c48f9ff57b71800913
https://github.com/WebKit/WebKit/commit/29c97727c5b3f512ab8448c48f9ff57b71800913
Author: David Kilzer <[email protected]>
Date: 2026-08-05 (Wed, 05 Aug 2026)
Changed paths:
M Source/WebKit/Platform/cocoa/WebPrivacyHelpers.mm
Log Message:
-----------
Cherry-pick [email protected] (97c98b40f0a7).
https://bugs.webkit.org/show_bug.cgi?id=317126
Crash reading process-global tracker address lists from the network
resolver thread in
WebPrivacyHelpers
<https://bugs.webkit.org/show_bug.cgi?id=317126>
<rdar://179437288>
Reviewed by Charlie Wolfe.
The tracker-lookup callback installed by
`configureForAdvancedPrivacyProtections()` reads the process-global
`version4List()`/`version6List()` on a network resolver dispatch thread,
but the `requestTrackerNetworkAddresses` completion handler rebuilds
those lists on every WebPrivacy update from a different thread. Nothing
serializes the two, so
an
update
can free a list's backing buffer while
the resolver thread is still walking it, leaving the resolver thread
reading freed memory.
`find()` now returns the
matched entry by value because its caller reads
the entry's members after the lookup returns. A borrowed pointer into
the shared buffer could not safely outlive the lock that protects it.
No new tests since this is a data race with no deterministic
reproduction. The
`WTF_REQUIRES_LOCK` annotations on the list accessors
make any access that does not hold the lock a compile error, which is
the load-bearing guarantee that the race cannot reappear.
* Source/WebKit/Platform/cocoa/WebPrivacyHelpers.mm:
(WebKit::TrackerAddressLookupInfo::populateIfNeeded):
(WebKit::TrackerAddressLookupInfo::find):
(WebKit::TrackerAddressLookupInfo::version4List):
(WebKit::TrackerAddressLookupInfo::version6List):
(WebKit::configureForAdvancedPrivacyProtections):
Identifier: [email protected]
Canonical link:
https://flagged.apple.com:443/proxy?t2=DW0Q9Y2zY2&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzA1ODc3LjEwNTFAd2Via2l0Z2xpYi8yLjUy&emid=a7631625-ea85-4f5d-ad00-6c0ba34c7439&c=11
Commit: 3fb9798c5b49d896e1dd5682d40ffb4e805c709e
https://github.com/WebKit/WebKit/commit/3fb9798c5b49d896e1dd5682d40ffb4e805c709e
Author: David Kilzer <[email protected]>
Date: 2026-08-05 (Wed, 05 Aug 2026)
Changed paths:
M Source/WebKit/Platform/cocoa/WebPrivacyHelpers.mm
Log Message:
-----------
Cherry-pick
[email protected] (f1ce3d547a23).
https://bugs.webkit.org/show_bug.cgi?id=317163
Data race reading the
process-global TrackerDomainLookupInfo map from the network resolver thread in
WebPrivacyHelpers
<https://bugs.webkit.org/show_bug.cgi?id=317163>
<rdar://164366001>
Reviewed by Charlie Wolfe.
The tracker-lookup callback installed by
`configureForAdvancedPrivacyProtections()` reads the process-global
`MemoryCompactRobinHoodHashMap` returned by `list()` on a network
resolver
dispatch thread, but the `requestTrackerDomainNamesData`
completion handler inserts into that same map on every WebPrivacy
update from a different thread.
Nothing serializes the two, so an
update can rehash and free the map's backing store while the resolver
thread is reading it, leaving the resolver thread reading freed memory.
The `find()` method already returns the matched entry by value, so no
signature change is
needed. The lock must still cover the `list().get()`
read because the read itself races the writer's rehash.
No new
tests since this is a data race with no deterministic
reproduction. The `WTF_REQUIRES_LOCK` annotation on the list accessor
makes any access that does not hold the lock a compile error, which is
the load-bearing guarantee that the race
cannot
reappear.
* Source/WebKit/Platform/cocoa/WebPrivacyHelpers.mm:
(WebKit::TrackerDomainLookupInfo::populateIfNeeded):
(WebKit::TrackerDomainLookupInfo::find):
(WebKit::TrackerDomainLookupInfo::list):
Identifier: [email protected]
Canonical link:
https://flagged.apple.com:443/proxy?t2=do9o3q0AE3&o=aHR0cHM6Ly9jb21taXRzLndlYmtpdC5vcmcvMzA1ODc3LjEwNTJAd2Via2l0Z2xpYi8yLjUy&emid=a7631625-ea85-4f5d-ad00-6c0ba34c7439&c=11
Compare: https://github.com/WebKit/WebKit/compare/520c46fc63bc...3fb9798c5b49
To unsubscribe from these emails, change your notification
settings at https://github.com/WebKit/WebKit/settings/notifications
