[webkit-changes] [WebKit/WebKit] 374e38: Versioning.

[MyahCobbs]

  Branch: refs/heads/safari-7615.4.1.10-branch
  Home:   https://github.com/WebKit/WebKit
  Commit: 374e384b5e839c20f12afe854e12ac175dcb0119
      https://github.com/WebKit/WebKit/commit/374e384b5e839c20f12afe854e12ac175dcb0119
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-10-24 (Tue, 24 Oct 2023)

  Changed paths:
    M Configurations/Version.xcconfig

  Log Message:
  -----------
  Versioning.


  Commit: aad636ead9d4d21b796c61a955490019757768d1
      https://github.com/WebKit/WebKit/commit/aad636ead9d4d21b796c61a955490019757768d1
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-10-24 (Tue, 24 Oct 2023)

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

  Log Message:
  -----------
  Cherry-pick 58238f2ad1a0. rdar://116494411

    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

Identifier: 259548.944 at safari-7615.4.1.10-branch


  Commit: 8379fec23d6bc1a20c5f8bb2cea337eb1a821305
      https://github.com/WebKit/WebKit/commit/8379fec23d6bc1a20c5f8bb2cea337eb1a821305
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-10-24 (Tue, 24 Oct 2023)

  Changed paths:
    M Source/JavaScriptCore/heap/PreciseAllocation.cpp
    M Source/JavaScriptCore/heap/PreciseAllocation.h

  Log Message:
  -----------
  Cherry-pick 6ea412c32f09. rdar://117030110

    Adjust PreciseAllocation alignment offset to also factor in cache line alignment requirements.
    https://bugs.webkit.org/show_bug.cgi?id=262011
    rdar://115959633

    Reviewed by Keith Miller.

    We should ensure that the JSObject header word and its butterfly are always in the same cache line.
    See radar for details.

    All JSObjects are either allocated out of a MarkedBlock or as a PreciseAllocation.  All MarkedBlock
    allocations are aligned on 16 byte boundaries (the MarkedBlock::atomSize).  This means that it’s
    impossible to get this condition with a MarkedBlock allocated object.

    For PreciseAllocations, each allocation is preceded by a PreciseAllocation header (which is currently
    96 bytes in size), and a 8 to 16 byte padding depending on what is need to get the resultant object
    start address to start on an odd 8 byte boundary (i.e. but 3 is set).  With PreciseAllocations,
    depending on the size of the allocation and what memory slot the allocation comes from, there is a
    way to get the JSObject header and butterfly to span across a cache line boundary.

    This patch prevents this by dynamically adjusting the alignment padding at the start of the
    PreciseAllocation to ensure that the start address of the JSObject always lands at a spot where the
    header and butterfly does not span a cache line boundary.

    * Source/JavaScriptCore/heap/PreciseAllocation.cpp:
    (JSC::dataCacheLineSize):
    (JSC::isAlignedForPreciseAllocation):
    (JSC::isCacheAlignedForPreciseAllocation):
    (JSC::PreciseAllocation::tryCreate):
    (JSC::PreciseAllocation::tryReallocate):
    (JSC::PreciseAllocation::tryCreateForLowerTier):
    (JSC::PreciseAllocation::reuseForLowerTier):
    (JSC::PreciseAllocation::PreciseAllocation):
    * Source/JavaScriptCore/heap/PreciseAllocation.h:
    (JSC::PreciseAllocation::headerSize):
    (JSC::PreciseAllocation::basePointer const):

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

Identifier: 259548.945 at safari-7615.4.1.10-branch


  Commit: f907ab380a9a40efdd3354f8273ea10f230f115a
      https://github.com/WebKit/WebKit/commit/f907ab380a9a40efdd3354f8273ea10f230f115a
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-10-24 (Tue, 24 Oct 2023)

  Changed paths:
    M Source/JavaScriptCore/runtime/ArrayBufferView.h
    M Source/JavaScriptCore/runtime/DataView.cpp
    M Source/JavaScriptCore/runtime/GenericTypedArrayViewInlines.h
    M Source/JavaScriptCore/runtime/JSDataView.cpp
    M Source/JavaScriptCore/runtime/JSGenericTypedArrayViewInlines.h

  Log Message:
  -----------
  Cherry-pick ac9f4e07603c. rdar://117030239

    [JSC] Add extra hardening about incorrectly configured shared growable typed array view
    https://bugs.webkit.org/show_bug.cgi?id=262338
    rdar://116168654

    Reviewed by Mark Lam.

    This is adding extra hardening against wrongly configured shared growable typed array view materialization from SerializedScriptValue.
    This pattern must not happen from normal execution. This happens only when the current process gets a bug which can emit arbitrary serialized
    data. And since SharedArrayBuffer cannot be sent to the other process, this issue is confined in the current process. Given that the attacker
    is already getting a way to create arbitrary serialized data, probably this does not add much additionally, but just adding hardening for now
    as an extra safety.

    * Source/JavaScriptCore/runtime/ArrayBufferView.h:
    (JSC::ArrayBufferView::verifySubRangeLength):
    * Source/JavaScriptCore/runtime/DataView.cpp:
    (JSC::DataView::wrappedAs):
    * Source/JavaScriptCore/runtime/GenericTypedArrayViewInlines.h:
    (JSC::GenericTypedArrayView<Adaptor>::tryCreate):
    (JSC::GenericTypedArrayView<Adaptor>::wrappedAs):
    * Source/JavaScriptCore/runtime/JSDataView.cpp:
    (JSC::JSDataView::create):
    * Source/JavaScriptCore/runtime/JSGenericTypedArrayViewInlines.h:
    (JSC::JSGenericTypedArrayView<Adaptor>::create):

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

Identifier: 259548.946 at safari-7615.4.1.10-branch


  Commit: a1060619ebb29eabaee8eb6f2171accde3446c5a
      https://github.com/WebKit/WebKit/commit/a1060619ebb29eabaee8eb6f2171accde3446c5a
  Author: Myah Cobbs <mcobbs 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 505f26eea3a5. rdar://116494487

    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

Identifier: 259548.947 at safari-7615.4.1.10-branch


  Commit: f69c6bd749ddad4009785ce2bbc5c90c55103aff
      https://github.com/WebKit/WebKit/commit/f69c6bd749ddad4009785ce2bbc5c90c55103aff
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-10-24 (Tue, 24 Oct 2023)

  Changed paths:
    M LayoutTests/fast/storage/serialized-script-value.html
    M Source/WebCore/bindings/js/SerializedScriptValue.cpp

  Log Message:
  -----------
  Cherry-pick 401705903095. rdar://117030146

    An Array index in CloneSerializer and CloneDeserializer can be confused for NonIndexPropertiesTag.
    https://bugs.webkit.org/show_bug.cgi?id=262616
    rdar://116034413

    Reviewed by Keith Miller, Sihui Liu and Chris Dumez.

    CloneSerializer and CloneDeserializer were previously using NonIndexPropertiesTag as the terminator of
    the indexed property section of an Array.  However, NonIndexPropertiesTag's encoding is 0xFFFFFFFD,
    which is less than MAX_ARRAY_INDEX (0xFFFFFFFE) i.e. an index of 0xFFFFFFFD can be confused for the
    NonIndexPropertiesTag, resulting type confusion.

    This patch changes the structure of a serialized Array to always terminate its indexed property section
    with a TerminatorTag (0xFFFFFFFF) first before looking for either a NonIndexPropertiesTag or another
    TerminatorTag.  The presence of a NonIndexPropertiesTag after the 1st TerminatorTag indicates the
    presence of a non-indexed properties section.  The presense of a TerminatorTag immediately after the
    1st TerminatorTag indicates that the non-indexed properties section is empty.

    Also updated the comment describing the shape of a serialized Array, and rebased a test.

    * LayoutTests/fast/storage/serialized-script-value.html:
    * Source/WebCore/bindings/js/SerializedScriptValue.cpp:
    (WebCore::CloneSerializer::serialize):
    (WebCore::CloneDeserializer::deserialize):

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

Identifier: 259548.948 at safari-7615.4.1.10-branch


  Commit: 330329f9efcacc89b01fc14e843ee96a471da5bf
      https://github.com/WebKit/WebKit/commit/330329f9efcacc89b01fc14e843ee96a471da5bf
  Author: Myah Cobbs <mcobbs at apple.com>
  Date:   2023-10-24 (Tue, 24 Oct 2023)

  Changed paths:
    A LayoutTests/fast/dom/HTMLObjectElement/updateWidget-crash-expected.txt
    A LayoutTests/fast/dom/HTMLObjectElement/updateWidget-crash.html
    M Source/WebCore/html/HTMLPlugInImageElement.cpp

  Log Message:
  -----------
  Cherry-pick c34793cc5793. rdar://117030934

    Assertion hit under Document::dispatchPagehideEvent()
    https://bugs.webkit.org/show_bug.cgi?id=263204
    rdar://116715579

    Reviewed by Ryosuke Niwa.

    Delay the load if we're not allowed to run script right now. Scheduling a load will
    cancel / stop any pending load, which may cause events to be fired and script to run.

    The synchronous code path is kept when we're allowed to run script to avoid breaking
    tests such as:
    - imported/w3c/web-platform-tests/css/css-writing-modes/abs-pos-non-replaced-icb-vlr-*.xht
    - imported/w3c/web-platform-tests/html/semantics/embedded-content/the-iframe-element/sandbox_004.htm
    - imported/blink/svg/dom/viewspec-*.html
    - fast/css/acid2.html

    * LayoutTests/fast/dom/HTMLObjectElement/updateWidget-crash-expected.txt: Added.
    * LayoutTests/fast/dom/HTMLObjectElement/updateWidget-crash.html: Added.
    * Source/WebCore/html/HTMLPlugInImageElement.cpp:
    (WebCore::HTMLPlugInImageElement::requestObject):

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

Identifier: 259548.949 at safari-7615.4.1.10-branch


Compare: https://github.com/WebKit/WebKit/compare/374e384b5e83%5E...330329f9efca