[webkit-changes] [WebKit/WebKit] 2deb5a: Cherry-pick 259548.185 at safari-7615-branch (41af95f...
Ryosuke Niwa
noreply at github.com
Mon Apr 3 16:12:08 PDT 2023
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 2deb5a6a1d3e324165fa7ece81bd996cce1b5b6c
https://github.com/WebKit/WebKit/commit/2deb5a6a1d3e324165fa7ece81bd996cce1b5b6c
Author: Chirag M Shah <chirag_m_shah at apple.com>
Date: 2023-04-03 (Mon, 03 Apr 2023)
Changed paths:
M Source/WebCore/loader/SubresourceLoader.cpp
Log Message:
-----------
Cherry-pick 259548.185 at safari-7615-branch (41af95f8b4e7). rdar://107561393
Clear the resource counter when releasingResources
https://bugs.webkit.org/show_bug.cgi?id=252200
rdar://104908871
Reviewed by Chris Dumez.
SubResourceLoader will clear the m_resource after releasing it, but the
resource counter still holds a raw pointer to it. This causes a UAF
issue. This fix clears the resource counter so that we don't end up
using it after releasing the resource.
* Source/WebCore/loader/SubresourceLoader.cpp:
(WebCore::SubresourceLoader::releaseResources):
Canonical link: https://commits.webkit.org/259548.185@safari-7615-branch
Canonical link: https://commits.webkit.org/262537@main
Commit: 5c3b82dd987db313b0f65593414cce90ea7373fc
https://github.com/WebKit/WebKit/commit/5c3b82dd987db313b0f65593414cce90ea7373fc
Author: Chirag M Shah <chirag_m_shah at apple.com>
Date: 2023-04-03 (Mon, 03 Apr 2023)
Changed paths:
M Source/WebCore/loader/SubresourceLoader.cpp
M Source/WebCore/loader/SubresourceLoader.h
M Source/WebCore/loader/cache/CachedResourceLoader.h
Log Message:
-----------
Cherry-pick 259548.186 at safari-7615-branch (1aa5ac3e3745). rdar://107561498
Use WeakPtr to track resources in SubresourceLoader
https://bugs.webkit.org/show_bug.cgi?id=252200
rdar://104908871
Reviewed by Chris Dumez.
CachedResource can get deallocated when the SubresourceLoader releases
its resources, in which case we'd be accessing a dangling pointer. This
change adopts WeakPtr for CachedResource so that we don't have a UAF.
* Source/WebCore/loader/SubresourceLoader.cpp:
(WebCore::SubresourceLoader::didFinishLoading):
(WebCore::SubresourceLoader::didFail):
* Source/WebCore/loader/SubresourceLoader.h:
* Source/WebCore/loader/cache/CachedResource.h:
* Source/WebCore/loader/cache/CachedResourceLoader.h:
Canonical link: https://commits.webkit.org/259548.186@safari-7615-branch
Canonical link: https://commits.webkit.org/262538@main
Commit: ed2ce1a96ed3b235f63511825007b4a58c437a48
https://github.com/WebKit/WebKit/commit/ed2ce1a96ed3b235f63511825007b4a58c437a48
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-04-03 (Mon, 03 Apr 2023)
Changed paths:
M Source/WebKit/Platform/Logging.h
M Source/WebKit/UIProcess/mac/SecItemShimProxy.cpp
M Source/WebKit/UIProcess/mac/SecItemShimProxy.h
Log Message:
-----------
Cherry-pick 259548.192 at safari-7615-branch (da35f298761e). rdar://107561523
Do IPC hardening in SecItemShimProxy::secItemRequest()
https://bugs.webkit.org/show_bug.cgi?id=252276
rdar://104253249
Reviewed by Alex Christensen and Geoffrey Garen.
Make sure the dictionaries that SecItemShimProxy::secItemRequest() receives
over IPC do not contain the kSecValueRef & kSecUseItemList keys. Those are
used to pass "in-memory" objects, which wouldn't work over IPC. We don't use
those keys but a compromised sending process could craft a dictionary with
these that could cause trouble when passed to the Keychain API.
* Source/WebKit/Platform/Logging.h:
* Source/WebKit/UIProcess/mac/SecItemShimProxy.cpp:
(WebKit::dictionaryContainsInMemoryObject):
(WebKit::SecItemShimProxy::secItemRequest):
Canonical link: https://commits.webkit.org/259548.192@safari-7615-branch
Canonical link: https://commits.webkit.org/262539@main
Commit: 0f50b1e44b8dcb5b2bb4a7ba3216737ba6817f9d
https://github.com/WebKit/WebKit/commit/0f50b1e44b8dcb5b2bb4a7ba3216737ba6817f9d
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2023-04-03 (Mon, 03 Apr 2023)
Changed paths:
A LayoutTests/fast/dom/focus-dialog-blur-input-type-change-crash-expected.txt
A LayoutTests/fast/dom/focus-dialog-blur-input-type-change-crash.html
A LayoutTests/platform/ios/fast/dom/focus-dialog-blur-input-type-change-crash-expected.txt
M Source/WebCore/dom/Document.cpp
Log Message:
-----------
Cherry-pick 259548.204 at safari-7615-branch (e110042815de). rdar://107561689
Nullptr crash in DateTimeFieldElement::isFocusable()
https://bugs.webkit.org/show_bug.cgi?id=252426
rdar://105383909
Reviewed by Aditya Keerthi and Wenson Hsieh.
The bug was caused by FocusController calling isFocusable() on a disconnected element of
the shadow tree of input element after blur event handler had changed the input type.
Fixed the crash by checking the connected-ness early and bailing out if it's disconnected.
* LayoutTests/fast/dom/focus-dialog-blur-input-type-change-crash-expected.txt: Added.
* LayoutTests/fast/dom/focus-dialog-blur-input-type-change-crash.html: Added.
* Source/WebCore/dom/Document.cpp:
(WebCore::Document::setFocusedElement):
Canonical link: https://commits.webkit.org/259548.204@safari-7615-branch
Canonical link: https://commits.webkit.org/262540@main
Commit: c07b4a95b6fab2ab901ce4190258e1ac9949d68c
https://github.com/WebKit/WebKit/commit/c07b4a95b6fab2ab901ce4190258e1ac9949d68c
Author: Eric Carlson <eric.carlson at apple.com>
Date: 2023-04-03 (Mon, 03 Apr 2023)
Changed paths:
A LayoutTests/ipc/wait-for-video-output-will-change-expected.txt
A LayoutTests/ipc/wait-for-video-output-will-change.html
M Source/WebCore/html/HTMLVideoElement.cpp
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerManagerProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerManagerProxy.h
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.cpp
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.h
M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.messages.in
Log Message:
-----------
Cherry-pick 259548.221 at safari-7615-branch (31f1a2d977a5). rdar://107561804
Crash in MediaPlayerPrivateAVFoundationObjC::waitForVideoOutputMediaDataWillChange
https://bugs.webkit.org/show_bug.cgi?id=252502
rdar://105448724
Reviewed by Chris Dumez.
If MediaPlayerPrivateAVFoundationObjC::waitForVideoOutputMediaDataWillChange doesn’t have
a video frame, it spins the runloop for up to one second waiting for AVFoundation to
generate one. If the page is reloaded while the runloop is spinning, the player may
have been deleted by the time waitForVideoOutputMediaDataWillChange resumes. Make
RemoteMediaPlayerManagerProxy refcounted and have it hold a self reference when calling
player methods that can call waitForVideoOutputMediaDataWillChange.
* LayoutTests/ipc/wait-for-video-output-will-change-expected.txt: Added.
* LayoutTests/ipc/wait-for-video-output-will-change.html: Added.
* Source/WebCore/html/HTMLVideoElement.cpp:
(WebCore::HTMLVideoElement::colorSpace const): Cleanup syntax.
(WebCore::HTMLVideoElement::nativeImageForCurrentTime): Hold a player ref while calling
nativeImageForCurrentTime.
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerManagerProxy.cpp:
(WebKit::RemoteMediaPlayerManagerProxy::createMediaPlayer): Store a proxy Ref instead of a
UniquePtr in the map.
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerManagerProxy.h:
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.cpp:
(WebKit::RemoteMediaPlayerProxy::create): New.
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.h:
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.messages.in: Now ref counted.
Canonical link: https://commits.webkit.org/259548.221@safari-7615-branch
Canonical link: https://commits.webkit.org/262541@main
Commit: 3f3fec2deac4dd9c010c7f640930a53287b87adc
https://github.com/WebKit/WebKit/commit/3f3fec2deac4dd9c010c7f640930a53287b87adc
Author: Chirag M Shah <chirag_m_shah at apple.com>
Date: 2023-04-03 (Mon, 03 Apr 2023)
Changed paths:
A LayoutTests/fast/rendering/render-tree-as-text-uaf-expected.txt
A LayoutTests/fast/rendering/render-tree-as-text-uaf.html
M Source/WebCore/rendering/RenderTreeAsText.cpp
Log Message:
-----------
Cherry-pick 259548.232 at safari-7615-branch (2009557bee01). rdar://107561932
Fix UAF in RenderTreeAsText for RenderWidget
https://bugs.webkit.org/show_bug.cgi?id=252580
rdar://105545826
Reviewed by Ryan Haddad and Darin Adler.
In write(), a call to view.layoutContext().layout() can result in the
deletion of the RenderWidget object, which results in a UAF. This change
fixes that by removing the call to layout, as that is already done for
the full frame tree from externalRepresentation.
* LayoutTests/fast/rendering/render-tree-as-text-uaf-expected.txt: Added.
* LayoutTests/fast/rendering/render-tree-as-text-uaf.html: Added.
* Source/WebCore/rendering/RenderTreeAsText.cpp:
(WebCore::write):
(WebCore::externalRepresentation):
Canonical link: https://commits.webkit.org/259548.232@safari-7615-branch
Canonical link: https://commits.webkit.org/262542@main
Commit: bc71ce15c3a0a920403d11756a43129edc2868a5
https://github.com/WebKit/WebKit/commit/bc71ce15c3a0a920403d11756a43129edc2868a5
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2023-04-03 (Mon, 03 Apr 2023)
Changed paths:
A JSTests/stress/loaded-argument-conflict-with-new-argument.js
M Source/JavaScriptCore/dfg/DFGArgumentsEliminationPhase.cpp
Log Message:
-----------
Cherry-pick 259548.261 at safari-7615-branch (89f337538ec6). rdar://107561976
[JSC] Loaded argument can be conflict with newly defined argument in arguments elimination phase
https://bugs.webkit.org/show_bug.cgi?id=252787
rdar://105671461
Reviewed by Mark Lam and Ryan Haddad.
We now correctly analyze interference between eliminated arguments and newly created arguments.
But this interference is analyzed based on the state *just before executing Node's effect".
For example, LoadVarargs elimination can get stackslots and put stackslots. And these stackslots
can interfere if stackslots are alive and not-interfered when LoadVarargs starts.
@a: CreateDirectArguments (loc0, loc1, loc2)
...
LoadVarargs @a, (loc2, loc3, loc4)
Load @a content, and define loc2, loc3, loc4 stackslots.
We check whether LoadVarargs itself is not interfering with the candidate's slots. This is because
LoadVarargs can be lowered to the sequence of PutStacks and we may OSR exit in the middle of these
PutStacks. So we would like to ensure that these PutStacks are not interfering with the candidate
nodes. We need this check only for LoadVarargs since it is the only node which can be lowered to
PutStacks in this phase.
And let's run storeArgumentCountIncludingThis at last since this is not included in interference analysis
since it is putting a constant.
* JSTests/stress/loaded-argument-conflict-with-new-argument.js: Added.
(foo):
(bar):
(baz):
* Source/JavaScriptCore/dfg/DFGArgumentsEliminationPhase.cpp:
Canonical link: https://commits.webkit.org/259548.261@safari-7615-branch
Canonical link: https://commits.webkit.org/262543@main
Commit: 1fe33ed99ed2e30af6991f97620896665f5b42da
https://github.com/WebKit/WebKit/commit/1fe33ed99ed2e30af6991f97620896665f5b42da
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2023-04-03 (Mon, 03 Apr 2023)
Changed paths:
A LayoutTests/editing/selection/redo-selection-restore-different-document-crash-expected.txt
A LayoutTests/editing/selection/redo-selection-restore-different-document-crash.html
M Source/WebCore/editing/Editor.cpp
M Source/WebCore/editing/VisibleSelection.cpp
Log Message:
-----------
Cherry-pick 259548.273 at safari-7615-branch (0501c9fc905e). rdar://107562054
Assertion failure in ContainerNode::removeAllChildrenWithScriptAssertion
https://bugs.webkit.org/show_bug.cgi?id=252785
rdar://105643144
Reviewed by Chris Dumez and Geoffrey Garen.
The bug was caused by Editor::changeSelectionAfterCommand setting selection pointing to a wrong document.
Fixed the bug by detecting this case and exiting early.
* LayoutTests/editing/selection/redo-selection-restore-different-document-crash-expected.txt: Added.
* LayoutTests/editing/selection/redo-selection-restore-different-document-crash.html: Added.
* Source/WebCore/editing/Editor.cpp:
(WebCore::Editor::changeSelectionAfterCommand):
* Source/WebCore/editing/VisibleSelection.cpp:
(WebCore::VisibleSelection::document const): Now returns the document of m_anchor when base is null but anchor isn't.
Canonical link: https://commits.webkit.org/259548.273@safari-7615-branch
Canonical link: https://commits.webkit.org/262544@main
Compare: https://github.com/WebKit/WebKit/compare/4c6725440012...1fe33ed99ed2
More information about the webkit-changes
mailing list