Branch: refs/heads/safari-7620.1.16.12-branch
Home: https://github.com/WebKit/WebKit
Commit: 596b55d223a8847815380f1a3aef67575f76e390
https://github.com/WebKit/WebKit/commit/596b55d223a8847815380f1a3aef67575f76e390
Author: Mohsin Qureshi <[email protected]>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7620.1.16.12.1
Canonical link: https://commits.webkit.org/[email protected]
Commit: d7095b77404a77c3f449fdb02cf014e052e88912
https://github.com/WebKit/WebKit/commit/d7095b77404a77c3f449fdb02cf014e052e88912
Author: Kiet Ho <[email protected]>
Date: 2024-11-07 (Thu, 07 Nov 2024)
Changed paths:
A LayoutTests/fast/dom/view-transition-lifetime-crash-expected.txt
A LayoutTests/fast/dom/view-transition-lifetime-crash.html
M Source/WebCore/Modules/screen-wake-lock/WakeLockManager.cpp
M Source/WebCore/Modules/screen-wake-lock/WakeLockManager.h
M Source/WebCore/Modules/screen-wake-lock/WakeLockSentinel.cpp
M Source/WebCore/dom/Document.cpp
M Source/WebCore/dom/ViewTransition.cpp
M Source/WebCore/dom/ViewTransition.h
M Source/WebCore/dom/VisibilityChangeClient.h
Log Message:
-----------
Cherry-pick 430e2dd31ad1. rdar://138799302
Cherry-pick c8d323b1851e. rdar://139301982
REGRESSION (283084@main): Document::visibilityStateChanged does not
hold reference to callback clients
rdar://138799302
https://bugs.webkit.org/show_bug.cgi?id=282360
Reviewed by Tim Nguyen, Ryosuke Niwa, and Chris Dumez.
Document::visibilityStateChanged() invokes visibility state callback
clients, but does not
hold a reference to them before invoking. The client could then
accidentally free itself
and cause an UAF. One possible route that leads to an UAF is through
ViewTransition,
which the test case demonstrates:
* The ViewTransition C++ objects are allocated by
document.startViewTransition().
After the call, each object has a ref count of at least 2 (one in the
JS wrapper
that wraps the C++ object, one in Document::m_activeViewTransition)
* The GC is invoked, which releases the JS wrappers and decreases the
ref count to 1
* The document visibility state is changed. This invokes
ViewTransition::visibilityStateChanged
on each object, which calls ::skipViewTransition, which calls
::clearViewTransition.
::clearViewTransition sets Document::m_activeViewTransition to null,
so the object ref
count is 0 and it's deallocated. ::clearViewTransition then continues
to modify the
(already deallocated) object, leading to an UAF.
Fix this by holding a reference to the callback clients before invoking
it. This involves
making VisibilityChangeClient ref counted. Then
Document::visibilityStateChanged()
would hold a reference to the client before invoking it. As
WakeLockManager
(which inherits VisibilityChangeClient) wasn't ref counted, this patch
also makes it
ref counted.
It's also observed that the JS wrapper should not be deallocated by the
GC before the
view transition has completed. This commit fixes this by implementing
ViewTransition::virtualHasPendingActivity(), which the GC consults to
determine whether
to deallocate the wrapper or not.
* LayoutTests/fast/dom/view-transition-lifetime-crash-expected.txt:
Added.
* LayoutTests/fast/dom/view-transition-lifetime-crash.html: Added.
* Source/WebCore/Modules/screen-wake-lock/WakeLockManager.cpp:
(WebCore::WakeLockManager::ref const): Delegated ref() to the document.
(WebCore::WakeLockManager::deref const): Delegated deref() to the
document.
* Source/WebCore/Modules/screen-wake-lock/WakeLockManager.h: Made
WakeLockManager ref counted by declaring ref() and deref().
* Source/WebCore/Modules/screen-wake-lock/WakeLockSentinel.cpp:
(WebCore::WakeLockSentinel::release): Hold a reference to the
document's WakeLockManager before using it.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::visibilityStateChanged): Hold a reference to the
visibility state callback client before calling it.
(WebCore::Document::wakeLockManager): Used
makeUniqueWithoutRefCountedCheck to create new WakeLockManager.
* Source/WebCore/dom/ViewTransition.cpp:
(WebCore::ViewTransition::virtualHasPendingActivity const): Added
implementation.
* Source/WebCore/dom/ViewTransition.h:
* Source/WebCore/dom/VisibilityChangeClient.h: Made
VisibilityChangeClient ref counted.
Canonical link: https://commits.webkit.org/286136@main
Canonical link: https://commits.webkit.org/283286.444@safari-7620-branch
Commit: fe8834d7ebe1f68cc1a03b006e7693722e6abfef
https://github.com/WebKit/WebKit/commit/fe8834d7ebe1f68cc1a03b006e7693722e6abfef
Author: Mohsin Qureshi <[email protected]>
Date: 2024-11-11 (Mon, 11 Nov 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7620.1.16.12.2
Canonical link: https://commits.webkit.org/[email protected]
Commit: fed3a0033b096450952a0a7c486480642e12d38f
https://github.com/WebKit/WebKit/commit/fed3a0033b096450952a0a7c486480642e12d38f
Author: Keith Miller <[email protected]>
Date: 2024-11-11 (Mon, 11 Nov 2024)
Changed paths:
M Source/WTF/wtf/LockAlgorithm.h
Log Message:
-----------
Cherry-pick 4d456933d70e. rdar://139645285
LockAlgorithm::unlockFast is too fast
https://bugs.webkit.org/show_bug.cgi?id=282865
rdar://139548123
Reviewed by Yusuke Suzuki.
Right now it has relaxed ordering but that's not correct since it means
writes to the critical section
could happen after the lock is unlocked. This could lead to arbitrary
crashes or other general badness.
* Source/WTF/wtf/LockAlgorithm.h:
(WTF::LockAlgorithm::unlockFast):
Canonical link: https://commits.webkit.org/283286.466@safari-7620-branch
Canonical link: https://commits.webkit.org/[email protected]
Commit: 8f7c98b9635519ac0341addfa5539d3a5f622579
https://github.com/WebKit/WebKit/commit/8f7c98b9635519ac0341addfa5539d3a5f622579
Author: Mohsin Qureshi <[email protected]>
Date: 2024-11-11 (Mon, 11 Nov 2024)
Changed paths:
M Source/WTF/wtf/LockAlgorithm.h
Log Message:
-----------
Revert 4d456933d70e. rdar://139645285
This reverts commit fed3a0033b096450952a0a7c486480642e12d38f.
Commit: f7c2ce90c4251f40b54e1eea0066b8494651e6bc
https://github.com/WebKit/WebKit/commit/f7c2ce90c4251f40b54e1eea0066b8494651e6bc
Author: Mohsin Qureshi <[email protected]>
Date: 2024-11-14 (Thu, 14 Nov 2024)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7620.1.16.12.3
Canonical link: https://commits.webkit.org/[email protected]
Commit: 1b78b5644ba597dcda6597f42d1d9fd148b59112
https://github.com/WebKit/WebKit/commit/1b78b5644ba597dcda6597f42d1d9fd148b59112
Author: Charlie Wolfe <[email protected]>
Date: 2024-11-14 (Thu, 14 Nov 2024)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.cpp
M Source/WebKit/NetworkProcess/NetworkProcess.h
M Source/WebKit/NetworkProcess/NetworkSession.cpp
M Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.cpp
M
Source/WebKit/NetworkProcess/SharedWorker/WebSharedWorkerServerConnection.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm
Log Message:
-----------
Cherry-pick 2815b4e29829. rdar://139887841
Data Isolation bypass via attacker controlled firstPartyForCookies
https://bugs.webkit.org/show_bug.cgi?id=283095
rdar://139818629
Reviewed by Matthew Finkel and Alex Christensen.
`NetworkProcess::allowsFirstPartyForCookies` unconditionally allows cookie
access for about:blank or
empty firstPartyForCookies URLs. We tried to remove this in
rdar://105733798 and rdar://107270673, but
we needed to revert both because there were rare and subtle bugs where
certain requests would incorrectly
have about:blank set as their firstPartyForCookies, causing us to kill the
WCP.
This patch is a lower risk change that removes the unconditional cookie
access for requests that have an
empty firstPartyForCookies, but will not kill the WCP that is incorrectly
sending an empty
firstPartyForCookies.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::createSocketChannel):
(WebKit::NetworkConnectionToWebProcess::scheduleResourceLoad):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOM):
(WebKit::NetworkConnectionToWebProcess::setCookiesFromDOM):
(WebKit::NetworkConnectionToWebProcess::cookiesEnabled):
(WebKit::NetworkConnectionToWebProcess::cookieRequestHeaderFieldValue):
(WebKit::NetworkConnectionToWebProcess::getRawCookies):
(WebKit::NetworkConnectionToWebProcess::cookiesForDOMAsync):
(WebKit::NetworkConnectionToWebProcess::setCookieFromDOMAsync):
(WebKit::NetworkConnectionToWebProcess::domCookiesForHost):
(WebKit::NetworkConnectionToWebProcess::establishSWContextConnection):
* Source/WebKit/NetworkProcess/NetworkProcess.cpp:
(WebKit::NetworkProcess::allowsFirstPartyForCookies):
* Source/WebKit/NetworkProcess/NetworkProcess.h:
* Source/WebKit/NetworkProcess/NetworkSession.cpp:
(WebKit::NetworkSession::addAllowedFirstPartyForCookies):
* Source/WebKit/NetworkProcess/ServiceWorker/WebSWServerConnection.cpp:
(WebKit::WebSWServerConnection::scheduleJobInServer):
*
Source/WebKit/NetworkProcess/SharedWorker/WebSharedWorkerServerConnection.cpp:
(WebKit::WebSharedWorkerServerConnection::requestSharedWorker):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/IPCTestingAPI.mm:
(EmptyFirstPartyForCookiesCookieRequestHeaderFieldValue)):
Canonical link: https://commits.webkit.org/283286.477@safari-7620-branch
Compare: https://github.com/WebKit/WebKit/compare/596b55d223a8%5E...1b78b5644ba5
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
