Branch: refs/heads/webkitglib/2.40
  Home:   https://github.com/WebKit/WebKit
  Commit: 5bcdabb358df7868634b33d3d48f6a270e80c157
      
https://github.com/WebKit/WebKit/commit/5bcdabb358df7868634b33d3d48f6a270e80c157
  Author: Yijia Huang <yijia_hu...@apple.com>
  Date:   2023-03-29 (Wed, 29 Mar 2023)

  Changed paths:
    A JSTests/wasm/stress/wasm-tuple-return.js
    M Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp

  Log Message:
  -----------
  Cherry-pick 252432.1029@safari-7614-branch (9dda7bfe768d). 
https://bugs.webkit.org/show_bug.cgi?id=250482

    LLInt WASM argument locals must be read before return values are written
    https://bugs.webkit.org/show_bug.cgi?id=250482
    rdar://103551585

    Reviewed by Justin Michaud.

    Given the wasm code which exports a wasm function `intFuncRef2` as a js 
function.
    ```
    (func (export "intFuncRef2") (param $p0 f32) (param $p1 funcref) (result 
i32 funcref)
        (i32.const 42)
        (local.get $p1)
        (return)
    )
    ```
    The corresponding dumped bytecodes show
    ```
    [   0] enter
    [   1] mov     dst:loc2, src:42(const0)
    [   4] mov     dst:loc3, src:loc2       // loc2 contains the funcref but 
now replaced with 42
    [   7] ret                              // return [loc2, loc3]
    ```
    which is wrong. Instead we should do
    ```
    [   0] enter
    [   1] mov     dst:loc18, src:42(const0)
    [   4] mov     dst:loc19, src:loc2
    [   7] mov     dst:loc2, src:loc18
    [  10] mov     dst:loc3, src:loc19
    [  13] ret
    ```
    Note that loc2 is both parameter and return lot.

    Locals usually need to be materialized on wasm stack when they are about to 
be or could
    be clobbered, usually before a control entry, a branch, or redefinition. 
Previously,
    Return writes only one value to the result slot that clobber one argument 
slot which
    is fine. Since now wasm function can return tuple that might bring us to 
the situation
    as shown in above example. We should materialize expression stack when 
return more than
    one values.

    * JSTests/wasm/stress/tuple-return.js: Added.
    (async test):
    * Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp:
    (JSC::Wasm::LLIntGenerator::addReturn):

    Canonical link: https://commits.webkit.org/252432.1029@safari-7614-branch


  Commit: 5bad5db3251c892ca60ff6f06d28479203d63a57
      
https://github.com/WebKit/WebKit/commit/5bad5db3251c892ca60ff6f06d28479203d63a57
  Author: Chris Dumez <cdu...@apple.com>
  Date:   2023-03-29 (Wed, 29 Mar 2023)

  Changed paths:
    M Source/WebCore/bindings/js/JSErrorHandler.cpp
    M Source/WebCore/bindings/js/JSEventListener.cpp
    M Source/WebCore/bindings/js/JSEventListener.h
    M Source/WebCore/bindings/js/JSLazyEventListener.cpp
    M Source/WebCore/bindings/js/WebCoreJSClientData.cpp
    M Source/WebCore/bindings/js/WebCoreJSClientData.h
    M Source/WebCore/dom/EventTarget.cpp
    M Source/WebCore/inspector/CommandLineAPIHost.cpp
    M Source/WebCore/inspector/WebInjectedScriptHost.cpp
    M Source/WebCore/inspector/agents/InspectorDOMAgent.cpp

  Log Message:
  -----------
  Cherry-pick 252432.1030@safari-7614-branch (433db4f29219). 
https://bugs.webkit.org/show_bug.cgi?id=246022

    Heap use-after-free in DOMWrapperWorld::~DOMWrapperWorld
    https://bugs.webkit.org/show_bug.cgi?id=246022
    rdar://100763856

    Reviewed by Jonathan Bedard and Ryosuke Niwa.

    Right before a worker terminates, it destroys its 
WorkerOrWorkletScriptController,
    which destroys the JS VM. Certain objects like DOMWrapperWorld cannot 
outlive
    the VM since they keep a `VM&' as data member. However, DOMWrapperWorld is
    refcounted and JSEventListeners hold a strong ref to their DOMWrapperWorld. 
If
    JSEventListeners outlive the VM, then it would lead to a use-after free in 
the
    DOMWrapperWorld destructor when destroying those JSEventListeners later on.

    We have previously made several attempts to try and unregister all event
    listeners before destroying the VM. However, those attempts were either
    incomplete or led to other crashes. I am therefore trying a different 
approach
    this time.

    JSEventListeners now register themselves as client of the JSVMClientData 
(which
    is owned by the VM) and the client gets a `willDestroyVM()` call before the
    VM gets destroyed. This allows JSEventListeners to clear out their data 
members
    which rely on the VM (DOMWrapperWorld and JSC::Weak data members).

    * Source/WebCore/bindings/js/JSErrorHandler.cpp:
    (WebCore::JSErrorHandler::handleEvent):
    * Source/WebCore/bindings/js/JSEventListener.cpp:
    (WebCore::JSEventListener::JSEventListener):
    (WebCore::JSEventListener::handleEvent):
    (WebCore::JSEventListener::functionName const):
    (WebCore::JSEventListener::willDestroyVM):
    * Source/WebCore/bindings/js/JSEventListener.h:
    (WebCore::JSEventListener::isolatedWorld const):
    (WebCore::JSEventListener::ensureJSFunction const):
    * Source/WebCore/bindings/js/JSLazyEventListener.cpp:
    (WebCore::JSLazyEventListener::initializeJSFunction const):
    * Source/WebCore/bindings/js/WebCoreJSClientData.cpp:
    (WebCore::JSVMClientData::~JSVMClientData):
    * Source/WebCore/bindings/js/WebCoreJSClientData.h:
    (WebCore::JSVMClientData::addClient):
    * Source/WebCore/dom/EventTarget.cpp:
    (WebCore::EventTarget::attributeEventListener):
    * Source/WebCore/inspector/CommandLineAPIHost.cpp:
    (WebCore::CommandLineAPIHost::getEventListeners):
    * Source/WebCore/inspector/WebInjectedScriptHost.cpp:
    (WebCore::objectForEventTargetListeners):
    * Source/WebCore/inspector/agents/InspectorDOMAgent.cpp:
    (WebCore::InspectorDOMAgent::buildObjectForEventListener):

    Canonical link: https://commits.webkit.org/252432.1030@safari-7614-branch


  Commit: 42498db72eabcb51b4f706c6da5b667fe517c943
      
https://github.com/WebKit/WebKit/commit/42498db72eabcb51b4f706c6da5b667fe517c943
  Author: David Degazio <35146201+ddega...@users.noreply.github.com>
  Date:   2023-03-29 (Wed, 29 Mar 2023)

  Changed paths:
    A JSTests/stress/cell-speculated-array-indexof.js
    M Source/JavaScriptCore/dfg/DFGFixupPhase.cpp

  Log Message:
  -----------
  Cherry-pick 252432.1031@safari-7614-branch (9f7e401c42a8). 
https://bugs.webkit.org/show_bug.cgi?id=250429

    Fix use-after-free in DFGFixupPhase for array indexOf
    https://bugs.webkit.org/show_bug.cgi?id=250429
    rdar://103852510

    Reviewed by Jonathan Bedard and Michael Saboff.

    During DFG fixup, array indexOf nodes are folded to -1 when the search 
element is speculated
    to be a different type than the array element (for instance, JSCell instead 
of Int32). When
    this happens, a speculation check is inserted, which can cause the DFG 
graph's varArgChildren
    array to reallocate. This invalidates the searchElement Edge reference, 
which we use
    immediately after the check insertion in the fixup phase. This patch fixes 
this potential
    use-after-free by grabbing the searchElement's associated node before 
inserting any checks,
    giving us a persistent pointer to a DFG node rather than a reference into a 
vector.

    * JSTests/stress/cell-speculated-array-indexof.js: Added.
    * Source/JavaScriptCore/dfg/DFGFixupPhase.cpp:
    (JSC::DFG::FixupPhase::fixupArrayIndexOf):

    Canonical link: https://commits.webkit.org/252432.1031@safari-7614-branch


  Commit: a4cc9fef4ed925d82d7e5af3b0d0c0e7d7aea67c
      
https://github.com/WebKit/WebKit/commit/a4cc9fef4ed925d82d7e5af3b0d0c0e7d7aea67c
  Author: Simon Fraser <simon.fra...@apple.com>
  Date:   2023-03-29 (Wed, 29 Mar 2023)

  Changed paths:
    M 
Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp

  Log Message:
  -----------
  Cherry-pick 252432.1033@safari-7614-branch (02e324c57689). 
https://bugs.webkit.org/show_bug.cgi?id=250742

    Possible type confusion bug in RemoteScrollingCoordinatorTransaction::decode
    https://bugs.webkit.org/show_bug.cgi?id=250742
    <rdar://102373218>

    Reviewed by Jonathan Bedard and Ryosuke Niwa.

    RemoteScrollingCoordinatorTransaction::decode() fails to check whether the 
nodeID returned by
    `m_scrollingStateTree->insertNode()` is a new one, different from the 
`nodeID` argument. If so, it
    could indicate that the node type of 
`m_scrollingStateTree->stateNodeForID()` does not match
    `nodeType`, leading to type confusion.

    In the UI process, `m_scrollingStateTree->insertNode()` should never return 
a different nodeID; this
    only happens when the given nodeType does not match the type of the 
existing node, which only
    happens in the WebProcess. So if `insertNode()` returns a different nodeID, 
or when the returned
    node doesn't have the expected type, we can consider it an IPC decoding 
error.

    * 
Source/WebKit/Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp:
    (WebKit::RemoteScrollingCoordinatorTransaction::decode):

    Canonical link: https://commits.webkit.org/252432.1033@safari-7614-branch


  Commit: 534a3a6ea4c438cab97a52ed16d0c61f763d0377
      
https://github.com/WebKit/WebKit/commit/534a3a6ea4c438cab97a52ed16d0c61f763d0377
  Author: Ryan Reno <rr...@apple.com>
  Date:   2023-03-29 (Wed, 29 Mar 2023)

  Changed paths:
    A 
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/generic/wildcard-host-checks-path.sub-expected.txt
    A 
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/generic/wildcard-host-checks-path.sub.html
    M Source/WebCore/page/csp/ContentSecurityPolicySource.cpp

  Log Message:
  -----------
  Cherry-pick 252432.1034@safari-7614-branch (3ee4a8321986). 
https://bugs.webkit.org/show_bug.cgi?id=250709

    CSP bypass due to incorrect handling of wildcard character in host 
expression
    https://bugs.webkit.org/show_bug.cgi?id=250709
    rdar://104335301

    Reviewed by Brent Fulgham and Jonathan Bedard.

    We were treating something like "https://*/foo"; as being a scheme-only 
source (so checking only against
    'https'). That is fixed by not only checking for the host-part being an 
empty string but also whether or not
    the host wildcard flag had been set by the CSP parser. Additionally, we 
were checking a given URL's host
    against the wildcard assuming a format like "*.com" instead of the 
possibility of the catch-all "*" wildcard.

    This change fixes our handling of the wildcard "*" in a directive's source 
list by correctly identifying when a
    source is scheme-only and by correctly taking into account the entire 
host-part wildcard grammar when checking
    a given host against a wildcard pattern.

    * 
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/generic/wildcard-host-checks-path.sub-expected.txt:
 Added.
    * 
LayoutTests/imported/w3c/web-platform-tests/content-security-policy/generic/wildcard-host-checks-path.sub.html:
 Added.
    * Source/WebCore/page/csp/ContentSecurityPolicySource.cpp:
    (WebCore::ContentSecurityPolicySource::hostMatches const):
    (WebCore::ContentSecurityPolicySource::isSchemeOnly const):

    Canonical link: https://commits.webkit.org/252432.1034@safari-7614-branch


Compare: https://github.com/WebKit/WebKit/compare/4524c8a9e1d4...534a3a6ea4c4
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to