[webkit-changes] [WebKit/WebKit] ed51f6: Cherry-pick 265870.234 at safari-7616-branch (9052a03...

Adrian Perez noreply at github.com
Thu Nov 2 08:43:41 PDT 2023


  Branch: refs/heads/webkitglib/2.42
  Home:   https://github.com/WebKit/WebKit
  Commit: ed51f64f11a291efe9b25e4e0131ae4ead8032c7
      https://github.com/WebKit/WebKit/commit/ed51f64f11a291efe9b25e4e0131ae4ead8032c7
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    M Source/WebKit/UIProcess/Media/cocoa/AudioSessionRoutingArbitratorProxyCocoa.mm

  Log Message:
  -----------
  Cherry-pick 265870.234 at safari-7616-branch (9052a0395b9b). https://bugs.webkit.org/show_bug.cgi?id=259836

    heap-use-after-free in WebKit::AudioSessionRoutingArbitratorProxy::logger
    https://bugs.webkit.org/show_bug.cgi?id=259836
    rdar://112774591

    Reviewed by Simon Fraser.

    Move the ALWAYS_LOG() inside the `if (weakThis)` scope since this macro will
    call `this->logger()`.

    * Source/WebKit/UIProcess/Media/cocoa/AudioSessionRoutingArbitratorProxyCocoa.mm:
    (WebKit::AudioSessionRoutingArbitratorProxy::beginRoutingArbitrationWithCategory):

    Canonical link: https://commits.webkit.org/265870.234@safari-7616-branch


  Commit: 363afd5bfd6fba06820cff9df4239a32197c6c17
      https://github.com/WebKit/WebKit/commit/363afd5bfd6fba06820cff9df4239a32197c6c17
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    M Source/WebCore/platform/mac/ScrollbarsControllerMac.mm

  Log Message:
  -----------
  Cherry-pick 265870.236 at safari-7616-branch (bf54ee3c4df6). https://bugs.webkit.org/show_bug.cgi?id=259890

    Use-after-free under WebCore::Scrollbar::supportsUpdateOnSecondaryThread()
    https://bugs.webkit.org/show_bug.cgi?id=259890
    rdar://113037440

    Reviewed by Ryosuke Niwa.

    Use a WeakPtr for _scrollbar instead of a raw pointer and add a null-check
    in [WebScrollbarPartAnimation setCurrentProgress:].

    * Source/WebCore/platform/mac/ScrollbarsControllerMac.mm:
    (-[WebScrollbarPartAnimation setCurrentProgress:]):
    (-[WebScrollerImpDelegate setUpAlphaAnimation:scrollerPainter:part:animateAlphaTo:duration:]):
    (-[WebScrollerImpDelegate scrollerImp:animateUIStateTransitionWithDuration:]):
    (-[WebScrollerImpDelegate scrollerImp:animateExpansionTransitionWithDuration:]):

    Canonical link: https://commits.webkit.org/265870.236@safari-7616-branch


  Commit: 9e4616081fec8a5cd51fa19300ea39bf897346dd
      https://github.com/WebKit/WebKit/commit/9e4616081fec8a5cd51fa19300ea39bf897346dd
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    M Source/WebCore/workers/service/ServiceWorkerGlobalScope.cpp
    M Source/WebCore/workers/service/ServiceWorkerGlobalScope.h

  Log Message:
  -----------
  Cherry-pick 265870.237 at safari-7616-branch (76715edd316d). https://bugs.webkit.org/show_bug.cgi?id=259896

    Potential use-after-free of the VM under ~FetchEvent()
    https://bugs.webkit.org/show_bug.cgi?id=259896
    rdar://113148936

    Reviewed by Brent Fulgham.

    The VM gets destroyed in between the call for WorkerGlobalScope::prepareForDestruction()
    and the call for the WorkerGlobalScope destructor. The crash trace indicates that
    the ServiceWorkerGlobalScope destructor destroys FetchEvent objects which end up needing
    the VM in their destructor.

    This is a speculative fix as I cannot reproduce the issue. Brady already imported the
    test case at 266608 at main.

    * Source/WebCore/workers/service/ServiceWorkerGlobalScope.cpp:
    (WebCore::ServiceWorkerGlobalScope::prepareForDestruction):
    * Source/WebCore/workers/service/ServiceWorkerGlobalScope.h:

    Canonical link: https://commits.webkit.org/265870.237@safari-7616-branch


  Commit: 3942867fc18d2c089c0e230b48a82f71d9cd3669
      https://github.com/WebKit/WebKit/commit/3942867fc18d2c089c0e230b48a82f71d9cd3669
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    M Source/WebKit/UIProcess/WebPageProxy.cpp
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm

  Log Message:
  -----------
  Cherry-pick 265870.357 at safari-7616-branch (8e677b301cae). https://bugs.webkit.org/show_bug.cgi?id=260046

    Main frame URL is wrong after server-side redirect to a page serving the COOP header
    https://bugs.webkit.org/show_bug.cgi?id=260046
    rdar://111855179

    Reviewed by Brent Fulgham and Alex Christensen.

    In the poc, the page is opening a popup (without opener) to the same origin URL1.
    This URL1 does a server-side redirect to URL2 which serves the `COOP: same-origin`
    HTTP header. After the navigation, Safari was displaying URL1 instead of URL2 in
    the URL bar.

    It is important to note that that 2 process-swap occur here. The first occurs when
    we do the navigation to URL1 in a popup that doesn't have an opener (in the
    decidePolicyForNavigationAction). The second one occurs when we receive the
    COOP header from URL2 (on navigation response).

    In ProvisionalPageProxy::didCreateMainFrame(), we have code which does the following:
    ```
    if (previousMainFrame && !previousMainFrame->provisionalURL().isEmpty()) {
            // In case of a process swap after response policy, the didStartProvisionalLoad already happened but the new main frame doesn't know about it
            // so we need to tell it so it can update its provisional URL.
            m_mainFrame->didStartProvisionalLoad(previousMainFrame->provisionalURL());
        }
    ```

    During the second process-swap, we forward the provisional URL from the committed
    frame to the provisional one. This is because the didStartProvisionalLoad IPC was
    handled by the committed main frame, before we decided to process-swap on resource
    response later on. As a result, the provisional main frame doesn't know yet about
    the provisional load and we have to let it know about it so it sets its provisional
    URL.

    This worked fine in the usual case where the COOP process-swap doesn't follow
    another process swap. However, in this case, the provisional URL got updated by
    an earlier server side redirect which got handled by a provisional frame, not the
    committed one. As a result, the committed frame didn't know about the latest
    provisional URL, only the original one before the server side redirect.

    To address the issue, whenever a provisional main frame receives a server-side
    redirect, we now let the committed main frame know about it too so that the
    committed frame's provisional URL always stays up-to-date. As a result, when
    ProvisionalPageProxy::didCreateMainFrame() forwards the committed frame's URL to
    the new provisional frame, it is now accurate.

    * Source/WebKit/UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::didReceiveServerRedirectForProvisionalLoadForFrameShared):
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/ProcessSwapOnNavigation.mm:

    Canonical link: https://commits.webkit.org/265870.357@safari-7616-branch


  Commit: d1631eb8f0f589b64da570fa1d075001fe47da50
      https://github.com/WebKit/WebKit/commit/d1631eb8f0f589b64da570fa1d075001fe47da50
  Author: Michael Saboff <msaboff at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    M JSTests/stress/regexp-vflag-property-of-strings.js
    M Source/JavaScriptCore/yarr/YarrPattern.cpp

  Log Message:
  -----------
  Cherry-pick 265870.381 at safari-7616-branch (b5b70c4574a7). https://bugs.webkit.org/show_bug.cgi?id=260173

    CrashOnOverflow in CharacterClassConstructor::compareUTF32Strings
    https://bugs.webkit.org/show_bug.cgi?id=260173
    rdar://113872060

    Reviewed by Ryosuke Niwa.

    Fixed and simplified the the sort comparison function compareUTF32Strings() to properly handle
    zero length strings.

    Added relevant tests.

    * JSTests/stress/regexp-vflag-property-of-strings.js:
    * Source/JavaScriptCore/yarr/YarrPattern.cpp:
    (JSC::Yarr::CharacterClassConstructor::compareUTF32Strings):

    Canonical link: https://commits.webkit.org/265870.381@safari-7616-branch


  Commit: 9d9d58fcd5689f18b64a9ced321111cc336841a6
      https://github.com/WebKit/WebKit/commit/9d9d58fcd5689f18b64a9ced321111cc336841a6
  Author: J Pascoe <j_pascoe at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    M Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.h
    M Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm

  Log Message:
  -----------
  Cherry-pick 265870.403 at safari-7616-branch (43c01fefcaa5). https://bugs.webkit.org/show_bug.cgi?id=260100

    Check CSP and X-Frame-Options for subframe AppSSO
    https://bugs.webkit.org/show_bug.cgi?id=260100
    rdar://108625087

    Reviewed by Alex Christensen.

    Before this patch, AppSSO unconditionally sets cookies whenever
    a session occurs without considering the headers in the response.
    This patch starts considering CSP and X-Frame-Options for AppSSO responses.

    Added API tests for this behavior.

    * Source/WebKit/UIProcess/API/APIFrameInfo.h:
    * Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.h:
    * Source/WebKit/UIProcess/Cocoa/SOAuthorization/SOAuthorizationSession.mm:
    (WebKit::SOAuthorizationSession::complete):
    (WebKit::SOAuthorizationSession::shouldInterruptLoadForXFrameOptions):
    (WebKit::SOAuthorizationSession::shouldInterruptLoadForCSPFrameAncestorsOrXFrameOptions):
    (): Deleted.
    * Tools/TestWebKitAPI/Tests/WebKitCocoa/SOAuthorizationTests.mm:
    (TestWebKitAPI::TEST):

    Canonical link: https://commits.webkit.org/265870.403@safari-7616-branch


  Commit: 9ef1b0b4d50a234078c2f81d1e4bfc31176c0c03
      https://github.com/WebKit/WebKit/commit/9ef1b0b4d50a234078c2f81d1e4bfc31176c0c03
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    A JSTests/stress/date-set-time-purify-nan.js
    M Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp
    M Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp

  Log Message:
  -----------
  Cherry-pick 265870.404 at safari-7616-branch (aa32244a89e7). https://bugs.webkit.org/show_bug.cgi?id=260497

    [JSC] Purify NaN for Date#setTime DFG / FTL implementations
    https://bugs.webkit.org/show_bug.cgi?id=260497
    rdar://114177456

    Reviewed by Mark Lam.

    Date#setTime should purify NaN, otherwise, it can put arbitrary NaN boxed values, and cause type-confusion.
    We can just use canonical NaN when the input is NaN.

    * JSTests/stress/date-set-time-purify-nan.js: Added.
    (opt):
    (main):
    * Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp:
    (JSC::DFG::SpeculativeJIT::compileDateSet):
    * Source/JavaScriptCore/ftl/FTLLowerDFGToB3.cpp:
    (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):

    Canonical link: https://commits.webkit.org/265870.404@safari-7616-branch


  Commit: bf680fe857b85b3c04f906f674ed21422d5d14fd
      https://github.com/WebKit/WebKit/commit/bf680fe857b85b3c04f906f674ed21422d5d14fd
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    A JSTests/stress/same-offset-different-property-name-multiple-get-by-variants.js
    M Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h
    M Source/JavaScriptCore/dfg/DFGGraph.cpp
    M Source/JavaScriptCore/dfg/DFGGraph.h

  Log Message:
  -----------
  Cherry-pick 265870.440 at safari-7616-branch (965be685c2ff). https://bugs.webkit.org/show_bug.cgi?id=260678

    [JSC] DFG AI GetById adhoc folding should insert watchpoints for structures
    https://bugs.webkit.org/show_bug.cgi?id=260678
    rdar://114072069

    Reviewed by Keith Miller.

    For DFG AI GetById's variants, they are tuples of StructureSet and offset.
    So, we should not obtain constant property just with offset since we first need to
    ensure that the base object is having a structure in StructureSet.
    Let's say [S0, 0] [S1, 1] variants are produced. In that case, we should not load
    a value from offset 1 when object is S0. But previously we were doing that since
    only thing we checked is that base is S0 or S1.
    This patch just extends DFG AI GetById handling to use existing tryGetConstantProperty
    mechanism with StructureSet. This properly inserts replacement watchpoints too, so that
    we can guarantee that the loaded value is inferred constant (if it gets different, then
    watchpoint fires). And we correctly check that the current object's structure is meeting
    the requirement against *variant*'s structure set.

    * JSTests/stress/same-offset-different-property-name-multiple-get-by-variants.js: Added.
    (main.const.object1):
    (main.const.object2):
    (main.const.object3):
    (main.get opt):
    (main):
    * Source/JavaScriptCore/dfg/DFGAbstractInterpreterInlines.h:
    (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
    * Source/JavaScriptCore/dfg/DFGGraph.cpp:
    (JSC::DFG::Graph::inferredValueForProperty):
    * Source/JavaScriptCore/dfg/DFGGraph.h:

    Canonical link: https://commits.webkit.org/265870.440@safari-7616-branch


  Commit: c78253385448723d17a89b7ebeb0b30586cecc44
      https://github.com/WebKit/WebKit/commit/c78253385448723d17a89b7ebeb0b30586cecc44
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/Region.cpp

  Log Message:
  -----------
  Cherry-pick 265870.452 at safari-7616-branch (ca4f7c9b9939). https://bugs.webkit.org/show_bug.cgi?id=260757

    WebContent may get killed due to invalid RemoteLayerTreeDrawingAreaProxy_CommitLayerTree IPC message
    https://bugs.webkit.org/show_bug.cgi?id=260757
    rdar://113860744

    Reviewed by Aditya Keerthi.

    The fuzzer found a case where the RemoteLayerTreeDrawingAreaProxy_CommitLayerTree
    IPC message may fail decoding because its contains an invalid IntRect. After some
    investigation, I found that we didn't handle overflows in the arithmetics in
    Region::Shape::bounds(), which means that we could end up with an IntRect that
    had a negative width or height.

    In the fuzzer case, we ended up with the following values:
    minX=-2147483648, minY=3, maxX=62, maxY=2306

    We would compute the width doing `62 - (-2147483648)` which would overflow and end
    up with a negative width. We now use checkedDifference<int32_t>() to detect
    overflows and clamp to std::numeric_limits<int32_t>::max() when it happens.

    * Source/WebCore/platform/graphics/Region.cpp:
    (WebCore::Region::Shape::bounds const):

    Canonical link: https://commits.webkit.org/265870.452@safari-7616-branch


  Commit: 610a6cbb21dcad1bf521bce0a288b965b498dfa9
      https://github.com/WebKit/WebKit/commit/610a6cbb21dcad1bf521bce0a288b965b498dfa9
  Author: Jer Noble <jer.noble at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    M Source/WebCore/Modules/mediarecorder/MediaRecorder.cpp
    M Source/WebCore/Modules/mediarecorder/MediaRecorder.h

  Log Message:
  -----------
  Cherry-pick 265870.463 at safari-7616-branch (f255dd40b82e). https://bugs.webkit.org/show_bug.cgi?id=260736

    CRASH in MediaRecorderPrivate::startRecording()
    https://bugs.webkit.org/show_bug.cgi?id=260736
    rdar://113544631

    Reviewed by Brent Fulgham and Eric Carlson.

    MediaRecorder can be destroyed before the completion handler passed to
    MediaRecorderPrivate::startRecording() is called. Detect this state by
    passing a WeakPtr into the completion handler lambda. Because MediaRecoder
    has multiple base classes which are CanMakeWeakPtr subclasses, disambiguate
    which subclass's WeakPtr implementation to use in the MediaRecoder class
    declaration.

    * Source/WebCore/Modules/mediarecorder/MediaRecorder.cpp:
    (WebCore::MediaRecorder::startRecording):
    * Source/WebCore/Modules/mediarecorder/MediaRecorder.h:

    Canonical link: https://commits.webkit.org/265870.463@safari-7616-branch


  Commit: f843025f13282977533aa26efcf93caf92f08710
      https://github.com/WebKit/WebKit/commit/f843025f13282977533aa26efcf93caf92f08710
  Author: Mark Lam <mark.lam at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    M Source/WebCore/bindings/js/SerializedScriptValue.cpp

  Log Message:
  -----------
  Cherry-pick 265870.467 at safari-7616-branch (1f9e21240663). https://bugs.webkit.org/show_bug.cgi?id=260822

    CloneDeserializer::readBigInt() should check for overflow when reifying JSBigInt length on 32-bit platforms.
    https://bugs.webkit.org/show_bug.cgi?id=260822
    rdar://114547822

    Reviewed by Chris Dumez.

    The serialized length is a number of Uint64 elements. On 32-bit platforms, this length gets multiplied by 2 in
    order to compute the actual length of the backing store to re-construct the JSBigInt.  Both the transmitted length
    and the JSBigInt length is stored as uint32_t.  Hence, the 2x multiplication can theoretically result in an
    overflow.  This patch adds an overflow check to handle this edge case.

    Also renamed lengthInUint64 to numberOfUint64Elements.  lengthInUint64 can be misread to mean a length stored as a
    uint64_t value, which is not what it actually means.  The length value is store in a uint32_t, and is a count of
    the number of uint64_t sized elements.

    * Source/WebCore/bindings/js/SerializedScriptValue.cpp:
    (WebCore::CloneSerializer::dumpHeapBigIntData):
    (WebCore::CloneDeserializer::readBigInt):

    Canonical link: https://commits.webkit.org/265870.467@safari-7616-branch


  Commit: 331906ed656dfe5747ade12430d445e0f5922d6d
      https://github.com/WebKit/WebKit/commit/331906ed656dfe5747ade12430d445e0f5922d6d
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    M Source/WebCore/html/HTMLInputElement.cpp
    M Source/WebCore/html/HTMLInputElement.h
    M Source/WebKit/Platform/spi/ios/UIKitSPI.h
    M Source/WebKit/Shared/FocusedElementInformation.h
    M Source/WebKit/Shared/FocusedElementInformation.serialization.in
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
    M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
    M Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm
    M Tools/TestWebKitAPI/ios/UIKitSPI.h

  Log Message:
  -----------
  Cherry-pick 265870.476 at safari-7616-branch (5cfdf9b1cbac). https://bugs.webkit.org/show_bug.cgi?id=260864

    [iOS] Keyboard should not learn autocorrections after revealing password in Gmail login flow
    https://bugs.webkit.org/show_bug.cgi?id=260864
    rdar://111393742

    Reviewed by Aditya Keerthi.

    When focusing and editing secure inputs (i.e. input type="password"), we set `isSecureTextEntry` on
    `UITextInputTraits` to `YES`, which disables autocorrection learning when the user types in this
    field, suppresses the keyboard in screen recordings, and more.

    However, some webpages (e.g. Gmail login) offer the ability to reveal the password as plain text as
    a convenience to the user — this typically works by changing the input type from `"password"` to
    just `"text"`. This currently causes all of the secure text entry behaviors to be disabled, which
    includes disabling correction learning; this is undesirable, since the password may be offered as an
    autocorrection candidate when editing in other plain text fields in the future, in non-secure
    contexts.

    Because the user opted to reveal the input, it doesn't really make sense to treat the input as fully
    secure (for instance, there's no reason to suppress keyboard visibility in screen recordings if the
    password text itself is fully visible). However, we need to (at least) prevent the keyboard from
    learning suggestions when typing in this field. To achieve this, we add a flag on `HTMLInputElement`
    to remember whether it was ever a password field; if so, we set the `-learnsCorrections` property on
    text input traits to `NO`.

    Test: AutocorrectionTests.DoNotLearnCorrectionsAfterChangingInputTypeFromPassword

    * Source/WebCore/html/HTMLInputElement.cpp:
    (WebCore::HTMLInputElement::runPostTypeUpdateTasks):

    Set `m_hasEverBeenPasswordField` here.

    * Source/WebCore/html/HTMLInputElement.h:
    (WebCore::HTMLInputElement::hasEverBeenPasswordField const):
    * Source/WebKit/Platform/spi/ios/UIKitSPI.h:
    * Source/WebKit/Shared/FocusedElementInformation.h:
    * Source/WebKit/Shared/FocusedElementInformation.serialization.in:
    * Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
    (-[WKContentView _updateTextInputTraits:]):

    Consult `hasEverBeenPasswordField` on the focused element information, and disable learning from
    corrections if it's set.

    * Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:

    Propagate `hasEverBeenPasswordField` state to the UI process when focusing an input element.

    (WebKit::WebPage::focusedElementInformation):
    * Tools/TestWebKitAPI/Tests/ios/AutocorrectionTestsIOS.mm:

    Add an API test to exercise the change.

    * Tools/TestWebKitAPI/ios/UIKitSPI.h:

    Canonical link: https://commits.webkit.org/265870.476@safari-7616-branch


  Commit: bdeaa5d7c60fa63947ecf14d6ab7246d45653a00
      https://github.com/WebKit/WebKit/commit/bdeaa5d7c60fa63947ecf14d6ab7246d45653a00
  Author: Antti Koivisto <antti at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    A LayoutTests/fast/css/style-scope-destruction-crash-expected.txt
    A LayoutTests/fast/css/style-scope-destruction-crash.html
    M Source/WebCore/rendering/PathOperation.cpp
    M Source/WebCore/rendering/PathOperation.h
    M Source/WebCore/style/StyleScope.cpp

  Log Message:
  -----------
  Cherry-pick 265870.481 at safari-7616-branch (382b02a5fc10). https://bugs.webkit.org/show_bug.cgi?id=260896

    heap-use-after-free | Style::Scope::removeStyleSheetCandidateNode; WebCore::SVGStyleElement::~SVGStyleElement; WebCore::ContainerNode::~ContainerNode
    https://bugs.webkit.org/show_bug.cgi?id=260896
    rdar://114231775

    Reviewed by Alan Baradlay.

    * LayoutTests/fast/css/style-scope-destruction-crash-expected.txt: Added.
    * LayoutTests/fast/css/style-scope-destruction-crash.html: Added.
    * Source/WebCore/rendering/PathOperation.cpp:
    (WebCore::ReferencePathOperation::ReferencePathOperation):
    (WebCore::ReferencePathOperation::element const): Deleted.

    Get rid of the unused element field. This creates a RenderStyle -> DOM ownership cycle which
    allows this crash to happen.

    * Source/WebCore/rendering/PathOperation.h:
    * Source/WebCore/style/StyleScope.cpp:
    (WebCore::Style::Scope::~Scope):

    Ensure we revoke weak pointers at the start of the destructor to avoid this class of problems.

    Canonical link: https://commits.webkit.org/265870.481@safari-7616-branch


  Commit: 20c4be22ba9848b0343a512040788af55f3d5a91
      https://github.com/WebKit/WebKit/commit/20c4be22ba9848b0343a512040788af55f3d5a91
  Author: David Kilzer <ddkilzer at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    M Source/WebCore/WebCore.xcodeproj/project.pbxproj
    M Source/WebCore/platform/audio/SincResampler.h

  Log Message:
  -----------
  Cherry-pick 265870.482 at safari-7616-branch (aae3b70b0eff). https://bugs.webkit.org/show_bug.cgi?id=260933

    Make WebCore::SincResampler testable
    https://bugs.webkit.org/show_bug.cgi?id=260933
    <rdar://114732348>

    Reviewed by Chris Dumez.

    * Source/WebCore/WebCore.xcodeproj/project.pbxproj:
    - Make SincResampler.h a private header.
    * Source/WebCore/platform/audio/SincResampler.h:
    (WebCore::SincResampler::processBuffer):
    - Export static class method.

    Canonical link: https://commits.webkit.org/265870.482@safari-7616-branch


  Commit: a30532513b4498ff1be9996add1de16696cc7dfa
      https://github.com/WebKit/WebKit/commit/a30532513b4498ff1be9996add1de16696cc7dfa
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-10-19 (Thu, 19 Oct 2023)

  Changed paths:
    M LayoutTests/TestExpectations
    A LayoutTests/fast/frames/frame-append-body-child-crash-expected.txt
    A LayoutTests/fast/frames/frame-append-body-child-crash.html
    M Source/WebCore/html/HTMLBodyElement.cpp

  Log Message:
  -----------
  Cherry-pick 265870.486 at safari-7616-branch (3fc6931dcc2c). https://bugs.webkit.org/show_bug.cgi?id=260907

    Crash under HTMLBodyElement::didFinishInsertingNode()
    https://bugs.webkit.org/show_bug.cgi?id=260907
    rdar://114177696

    Reviewed by Ryosuke Niwa.

    When a <body> is inserted into the document, `HTMLBodyElement::insertedIntoAncestor()`
    gets called. This function would only return `InsertedIntoAncestorResult::NeedsPostInsertionCallback`
    if `is<HTMLFrameElementBase>(document().ownerElement())`, causing `HTMLBodyElement::didFinishInsertingNode()`
    to get called later on. We would then assume in didFinishInsertingNode() that the document's owner element
    is a non-null HTMLFrameElementBase.

    However, as proven by the test, DOM manipulations can happen in between the 2 calls
    causing the assertion to no longer hold. To address the issue we now early return
    if `is<HTMLFrameElementBase>(document().ownerElement())` is no longer true in
    `HTMLBodyElement::didFinishInsertingNode()`.

    In the case of the test, `document().frame()` becomes null because the frame gets
    detached, causing `document().ownerElement()` to return null as well.

    * LayoutTests/fast/frames/frame-append-body-child-crash-expected.txt: Added.
    * LayoutTests/fast/frames/frame-append-body-child-crash.html: Added.
    * Source/WebCore/html/HTMLBodyElement.cpp:
    (WebCore::HTMLBodyElement::didFinishInsertingNode):

    Canonical link: https://commits.webkit.org/265870.486@safari-7616-branch


  Commit: e0e6399d979e76db566ad2eab38db8c9577d4837
      https://github.com/WebKit/WebKit/commit/e0e6399d979e76db566ad2eab38db8c9577d4837
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-10-20 (Fri, 20 Oct 2023)

  Changed paths:
    A LayoutTests/webaudio/audioworklet-bad-array-type-expected.txt
    A LayoutTests/webaudio/audioworklet-bad-array-type.html
    A LayoutTests/webaudio/bad-array-type-processor.js
    M Source/WebCore/Modules/webaudio/AudioWorkletProcessor.cpp

  Log Message:
  -----------
  Cherry-pick 265870.534 at safari-7616-branch (3be781681be0). https://bugs.webkit.org/show_bug.cgi?id=261289

    Bad jsCast<>() in copyDataFromJSArrayToBuses() in AudioWorkletProcessor.cpp
    https://bugs.webkit.org/show_bug.cgi?id=261289
    rdar://115042475

    Reviewed by Ryosuke Niwa.

    Use jsDynamicCast<>() instead of jsCast<>() in AudioWorkletProcessor.cpp for
    safety.

    * LayoutTests/webaudio/audioworklet-bad-array-type-expected.txt: Added.
    * LayoutTests/webaudio/audioworklet-bad-array-type.html: Added.
    * LayoutTests/webaudio/bad-array-type-processor.js: Added.
    (CustomProcessor.prototype.process):
    (CustomProcessor):
    * Source/WebCore/Modules/webaudio/AudioWorkletProcessor.cpp:
    (WebCore::toJSArray):
    (WebCore::toJSObject):
    (WebCore::copyDataFromJSArrayToBuses):
    (WebCore::AudioWorkletProcessor::process):

    Canonical link: https://commits.webkit.org/265870.534@safari-7616-branch


  Commit: 62bc9d115f69618d6ea221f616c72f64e13e1a7c
      https://github.com/WebKit/WebKit/commit/62bc9d115f69618d6ea221f616c72f64e13e1a7c
  Author: Alexey Shvayka <ashvayka at apple.com>
  Date:   2023-10-20 (Fri, 20 Oct 2023)

  Changed paths:
    A JSTests/stress/regress-114860483.js
    M Source/JavaScriptCore/runtime/JSObject.cpp
    M Source/JavaScriptCore/runtime/JSObjectInlines.h

  Log Message:
  -----------
  Cherry-pick 265870.535 at safari-7616-branch (049d074c4b1b). https://bugs.webkit.org/show_bug.cgi?id=261287

    JSObject::anyObjectInChainMayInterceptIndexedAccesses and JSObject::didBecomePrototype need to account for JSGlobalProxy
    https://bugs.webkit.org/show_bug.cgi?id=261287
    rdar://114860483

    Reviewed by Yusuke Suzuki.

    Since JSObject::anyObjectInChainMayInterceptIndexedAccesses() walks up the [[Prototype]] chain,
    whenever an indexed property is defined on a JSGlobalObject, we should add MayHaveIndexedAccessors
    flag to JSGlobalProxy instead.

    Currently, mayInterceptIndexedAccesses() is never queried on JSGlobalObject instances.

    This change also fixes mayBePrototype() to be queried from JSGlobalProxy rather than JSGlobalObject,
    which is correct given setPrototypeDirect() used to call didBecomePrototype() only on the proxy.
    However, for extra robustness, this we propagate didBecomePrototype() to the global object as well.

    * JSTests/stress/regress-114860483.js: Added.
    * Source/JavaScriptCore/runtime/JSObjectInlines.h:
    (JSC::JSObject::didBecomePrototype):
    * Source/JavaScriptCore/runtime/JSObject.cpp:
    (JSC::JSObject::notifyPresenceOfIndexedAccessors):

    Canonical link: https://commits.webkit.org/265870.535@safari-7616-branch


  Commit: da56ace715856dbed69d2a2fd79142a4cfd68997
      https://github.com/WebKit/WebKit/commit/da56ace715856dbed69d2a2fd79142a4cfd68997
  Author: Ryosuke Niwa <rniwa at webkit.org>
  Date:   2023-10-20 (Fri, 20 Oct 2023)

  Changed paths:
    A LayoutTests/animations/resolve-animation-should-not-execute-scripts-expected.txt
    A LayoutTests/animations/resolve-animation-should-not-execute-scripts.html
    M LayoutTests/platform/ios/imported/w3c/web-platform-tests/screen-orientation/active-lock-expected.txt
    M Source/WebCore/Modules/paymentrequest/PaymentRequest.cpp
    M Source/WebCore/Modules/paymentrequest/PaymentResponse.cpp
    M Source/WebCore/Modules/webaudio/OfflineAudioContext.cpp
    M Source/WebCore/animation/WebAnimation.cpp
    M Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp
    M Source/WebCore/dom/TaskSource.h
    M Source/WebCore/page/ScreenOrientation.cpp

  Log Message:
  -----------
  Cherry-pick 265870.536 at safari-7616-branch (6d865c4bf3da). https://bugs.webkit.org/show_bug.cgi?id=261256

    ScriptDisallowedScope bypass via a `then` getter in Document::updateStyleIfNeeded
    https://bugs.webkit.org/show_bug.cgi?id=261256
    <rdar://114545310>

    Reviewed by Ryosuke Niwa.

    This PR addresses several bugs:
    1. There is a ScriptDisallowedScope bypass via DeferredPromise::callFunction.
    2. WebAnimation::resolve() tries to execute scripts by rejecting promises during updateStyle.
    3. WebAnimation::cancel() and WebAnimation::resetPendingTasks() also tries to execute scripts by
    rejecting promises during updateStyle.
    4. PaymentRequest and PaymentResponse try to reject promises during active DOM object suspension
    as well as the script execution context is being stopped.
    5. WebAudio tries to reject promises during active DOM object suspension.

    For (1), this PR adds a release assertion in DeferredPromise::callFunction like the one we have in
    ScriptController::canExecuteScripts. Note this has to be a thread safe variant since this code can be
    executed in a worker thread.

    For (2), this PR makes WebAnimation::resolve call updateFinishedState with SynchronouslyNotify::No
    instead of SynchronouslyNotify::Yes. Note that in the spec [1], the only scenario in which this flag
    is set to yes is when the author script calls finish() on an Animation object.

    For (3), (4), and (5), this PR makes these actions asynchronous by scheduling a task / microtask
    instead of synchronously rejecting promises.

    [1] https://drafts.csswg.org/web-animations-1/#update-an-animations-finished-state

    Based on original patch by Ryosuke Niwa.

    * LayoutTests/animations/resolve-animation-should-not-execute-scripts-expected.txt: Added.
    * LayoutTests/animations/resolve-animation-should-not-execute-scripts.html: Added.

    * Source/WebCore/Modules/paymentrequest/PaymentRequest.cpp:
    (WebCore::PaymentRequest::~PaymentRequest): Now allows pending activity to exist when the associated
    script execution context had been stopped.
    (WebCore::PaymentRequest::stop): Don't try to settle the promise in the middle of stopping this
    active DOM object.
    (WebCore::PaymentRequest::suspend): Ditto for suspension. Schedule a task to settle promise instead.

    * Source/WebCore/Modules/paymentrequest/PaymentResponse.cpp:
    (WebCore::PaymentResponse::~PaymentResponse): Now allows pending activity to exist when
    the associated script execution context had been stopped.
    (WebCore::PaymentResponse::suspend): Don't try to settle the promise in the middle of stopping this
    active DOM object.

    * Source/WebCore/Modules/webaudio/OfflineAudioContext.cpp:
    (WebCore::OfflineAudioContext::uninitialize): Don't reject the promise when the active DOM objects
    had already been stopped.

    * Source/WebCore/animation/WebAnimation.cpp:
    (WebCore::WebAnimation::cancel): Reject the finished promise in a newly scheduled task instead of
    synchronously rejecting it, which would result in script execution.
    (WebCore::WebAnimation::resolve): Resolve the promise asynchronously.

    * Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp:
    (WebCore::DeferredPromise::callFunction): Added a release assertion.
    * Source/WebCore/dom/TaskSource.h:

    Canonical link: https://commits.webkit.org/265870.536@safari-7616-branch


  Commit: aa2b734db49912b00ea9b1fd38714a3ddc6d1d9c
      https://github.com/WebKit/WebKit/commit/aa2b734db49912b00ea9b1fd38714a3ddc6d1d9c
  Author: Abigail Fox <abigail_fox at apple.com>
  Date:   2023-10-20 (Fri, 20 Oct 2023)

  Changed paths:
    M Source/WTF/wtf/Vector.h

  Log Message:
  -----------
  Cherry-pick 265870.553 at safari-7616-branch (1393b618ad01). https://bugs.webkit.org/show_bug.cgi?id=261220

    WTF::Vector cross-container overflow ASAN support
    https://bugs.webkit.org/show_bug.cgi?id=261220
    rdar://113692853

    Reviewed by David Kilzer.

    Added check in ASAN builds for container overflow

    * Source/WTF/wtf/Vector.h:
    (WTF::Malloc>::asanBufferSizeWillChangeTo):
    (WTF::Malloc>::uncheckedAppend):
    * Tools/TestWebKitAPI/Tests/WTF/Vector.cpp:
    (TestWebKitAPI::TEST):

    Canonical link: https://commits.webkit.org/265870.553@safari-7616-branch


  Commit: 778c0252b606286f2015319504b2e944662ff697
      https://github.com/WebKit/WebKit/commit/778c0252b606286f2015319504b2e944662ff697
  Author: Youenn Fablet <youennf at gmail.com>
  Date:   2023-10-20 (Fri, 20 Oct 2023)

  Changed paths:
    M Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.cpp
    M Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.h

  Log Message:
  -----------
  Cherry-pick 265870.557 at safari-7616-branch (5dd0bac29991). https://bugs.webkit.org/show_bug.cgi?id=261200

    NetworkRTCProvider::doSocketTaskOnRTCNetworkThread should protect iself
    https://bugs.webkit.org/show_bug.cgi?id=261200
    rdar://112521277

    Reviewed by Eric Carlson.

    Make sure to ref NetworkRTCProvider before hopping to another thread.
    We mark NetworkRTCProvider as DestructionThread::MainRunLoop to ensure it gets destroyed in main run loop.

    * Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.cpp:
    (WebKit::NetworkRTCProvider::createClientTCPSocket):
    (WebKit::NetworkRTCProvider::doSocketTaskOnRTCNetworkThread):
    * Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.h:

    Canonical link: https://commits.webkit.org/265870.557@safari-7616-branch


  Commit: 4f150b6eca02e2d05719ade9dcb2cdb2868ea918
      https://github.com/WebKit/WebKit/commit/4f150b6eca02e2d05719ade9dcb2cdb2868ea918
  Author: Brandon Stewart <brandonstewart at apple.com>
  Date:   2023-10-20 (Fri, 20 Oct 2023)

  Changed paths:
    M Source/WebCore/crypto/SubtleCrypto.cpp

  Log Message:
  -----------
  Cherry-pick 265870.559 at safari-7616-branch (8e9332694594). https://bugs.webkit.org/show_bug.cgi?id=261519

    SubtleCrypto:wrapKey ensure promise is not garbage collected
    https://bugs.webkit.org/show_bug.cgi?id=261519
    rdar://115349445

    Reviewed by Tim Nguyen.

    We need to ensure that the promise always remains alive when in use.
    Adding a RefPtr guarantees that it will not be garbage collected.

    * Source/WebCore/crypto/SubtleCrypto.cpp:
    (WebCore::SubtleCrypto::wrapKey):

    Canonical link: https://commits.webkit.org/265870.559@safari-7616-branch


  Commit: 39906508cf32752207a10f77bf4fa96fe8b49f68
      https://github.com/WebKit/WebKit/commit/39906508cf32752207a10f77bf4fa96fe8b49f68
  Author: Andres Gonzalez <andresg_22 at apple.com>
  Date:   2023-10-20 (Fri, 20 Oct 2023)

  Changed paths:
    M Source/WebCore/accessibility/AXObjectCache.cpp

  Log Message:
  -----------
  Cherry-pick 265870.560 at safari-7616-branch (0f4469003671). rdar://113770369

    AX: Heap-use-after-free in WebCore::AXObjectCache::get(WebCore::Node*)+0x41c
    rdar://113770369

    Reviewed by Ryosuke Niwa.

    This UAF is most likely caused by a mutation in the WeakListHashSet while iterating over it. This patch avoids the problem by copying the set to a Vector and iterating over the Vector.
    The same technique is applied to another iteration over a WeakListHashsSet, m_deferredNodeAddedOrRemovedList, in the same method.

    * Source/WebCore/accessibility/AXObjectCache.cpp:
    (WebCore::AXObjectCache::performDeferredCacheUpdate):

    Canonical link: https://commits.webkit.org/265870.560@safari-7616-branch


  Commit: 466056288105e42969f244bd33862ef050925994
      https://github.com/WebKit/WebKit/commit/466056288105e42969f244bd33862ef050925994
  Author: Mark Lam <mark.lam at apple.com>
  Date:   2023-10-20 (Fri, 20 Oct 2023)

  Changed paths:
    M Source/WebCore/bindings/js/SerializedScriptValue.cpp

  Log Message:
  -----------
  Cherry-pick 265870.574 at safari-7616-branch (58238f2ad1a0). https://bugs.webkit.org/show_bug.cgi?id=261801

    CloneDeserializer should always purifyNaN all double values it reads.
    https://bugs.webkit.org/show_bug.cgi?id=261801
    rdar://115756664

    Reviewed by Yusuke Suzuki.

    CloneDeserializer::read() will now invoke purifyNaN() on any double values that it reads.
    As a result, we can remove the 2 purifyNaN calls in its client that are now redundant.

    * Source/WebCore/bindings/js/SerializedScriptValue.cpp:
    (WebCore::CloneDeserializer::read):
    (WebCore::CloneDeserializer::readTerminal):

    Canonical link: https://commits.webkit.org/265870.574@safari-7616-branch


  Commit: 325c110d98657180020871982ca9be36660ca789
      https://github.com/WebKit/WebKit/commit/325c110d98657180020871982ca9be36660ca789
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-10-24 (Tue, 24 Oct 2023)

  Changed paths:
    A LayoutTests/webaudio/promise-resolution-crash-expected.txt
    A LayoutTests/webaudio/promise-resolution-crash.html
    M Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp

  Log Message:
  -----------
  Cherry-pick 265870.579 at safari-7616-branch (587ed3048a75). https://bugs.webkit.org/show_bug.cgi?id=261829

    Regression(265870.536 at safari-7616-branch) Crashes under DeferredPromise::callFunction()
    https://bugs.webkit.org/show_bug.cgi?id=261829
    rdar://115712299

    Reviewed by Brent Fulgham and Mark Lam.

    The RELEASE_ASSERT() added by  Ryosuke in 265870.536 at safari-7616-branch in DeferredPromise::callFunction()
    is hitting a lot in the wild, from various call sites. The assertion makes sure we're allowed to run
    script when resolving a promise (i.e. we're not in the middle of layout or style resolution).

    * LayoutTests/webaudio/promise-resolution-crash-expected.txt: Added.
    * LayoutTests/webaudio/promise-resolution-crash.html: Added.
    New test coverage.

    * Source/WebCore/bindings/js/JSDOMPromiseDeferred.cpp:
    (WebCore::DeferredPromise::callFunction):
    Drop the release assertion and instead schedule a task to resolve the promise
    asynchronously when we're not allowed to run script, similarly to what we were
    already doing when b/f cache suspended.

    Canonical link: https://commits.webkit.org/265870.579@safari-7616-branch


  Commit: 027d2d68cdf8a5b7678015efbf98dfedf42e6e79
      https://github.com/WebKit/WebKit/commit/027d2d68cdf8a5b7678015efbf98dfedf42e6e79
  Author: Dan Robson <dtr_bugzilla at apple.com>
  Date:   2023-10-24 (Tue, 24 Oct 2023)

  Changed paths:
    M Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/resize_test.cc
    M Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/common/vp9_alloccommon.c
    M Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_encoder.c

  Log Message:
  -----------
  Cherry-pick 265870.611 at safari-7616.2.9.10-branch (6de839091b9f). <bug>

    Cherry-pick 505f26eea3a5. rdar://116293231

        VP9 additional changes related to CVE-2023-5217
        rdar://116293231

        Reviewed by Jean-Yves Avenard.

        Cherry-picking patches that do hardening of VP9 encoder reconfiguration:
        - 02ab555e992c191e5c509ed87b3cc48ed915b447
        - 263682c9a29395055f3b3afe2d97be1828a6223f

        I had to update CHECK_MEM_ERROR call site since we need to pass cm currently, while they do pass cm->error upstream.

        While we do not think we are exercising this code path of reconfiguring while encoding,
        it is future proof and low risk to cherry-pick these changes.

        * Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/test/resize_test.cc:
        * Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/common/vp9_alloccommon.c:
        (free_seg_map):
        (vp9_free_context_buffers):
        (vp9_alloc_context_buffers):
        * Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp9/encoder/vp9_encoder.c:
        (free_copy_partition_data):
        (vp9_change_config):

        Canonical link: https://commits.webkit.org/267815.170@safari-7617-branch

    Canonical link: https://commits.webkit.org/265870.611@safari-7616.2.9.10-branch


Compare: https://github.com/WebKit/WebKit/compare/2725c3d1aec9...027d2d68cdf8


More information about the webkit-changes mailing list