Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 2deb5a6a1d3e324165fa7ece81bd996cce1b5b6c
https://github.com/WebKit/WebKit/commit/2deb5a6a1d3e324165fa7ece81bd996cce1b5b6c
Author: Chirag M Shah <[email protected]>
Date: 2023-04-03 (Mon, 03 Apr 2023)
Changed paths:
M Source/WebCore/loader/SubresourceLoader.cpp
Log Message:
-----------
Cherry-pick 259548.185@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 <[email protected]>
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@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 <[email protected]>
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@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 <[email protected]>
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@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 <[email protected]>
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@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 <[email protected]>
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@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 <[email protected]>
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@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 <[email protected]>
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@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
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
