Branch: refs/heads/webkitglib/2.52
  Home:   https://github.com/WebKit/WebKit
  Commit: f2aafb6d2911da941d46749764e977802fec8689
      
https://github.com/WebKit/WebKit/commit/f2aafb6d2911da941d46749764e977802fec8689
  Author: Kristian Monsen <[email protected]>
  Date:   2026-06-12 (Fri, 12 Jun 2026)

  Changed paths:
    A LayoutTests/ipc/webrtc-create-socket-empty-address-crash-expected.txt
    A LayoutTests/ipc/webrtc-create-socket-empty-address-crash.html
    A LayoutTests/ipc/webrtc-send-to-socket-empty-address-crash-expected.txt
    A LayoutTests/ipc/webrtc-send-to-socket-empty-address-crash.html
    M Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.cpp

  Log Message:
  -----------
  Cherry-pick 314720@main (8aab904f7092). 
https://bugs.webkit.org/show_bug.cgi?id=315726

    Reject WebRTC socket creation with empty address to fix crash
    https://bugs.webkit.org/show_bug.cgi?id=315726
    rdar://177615751

    Reviewed by Youenn Fablet.

    NetworkRTCProvider::createUDPSocket and createClientTCPSocket on Cocoa 
would crash when passed a socket address with a nil IP and empty hostname.
    The crash occurred in nw_endpoint_create_host_with_numeric_port when called 
with an empty string.

    The fix adds an early check rejecting such addresses and calling 
signalSocketIsClosed to notify the caller gracefully instead of crashing.

    Test: ipc/webrtc-create-socket-empty-address-crash.html

    * LayoutTests/ipc/webrtc-create-socket-empty-address-crash-expected.txt: 
Added.
    * LayoutTests/ipc/webrtc-create-socket-empty-address-crash.html: Added.
    * LayoutTests/ipc/webrtc-send-to-socket-empty-address-crash-expected.txt: 
Added.
    * LayoutTests/ipc/webrtc-send-to-socket-empty-address-crash.html: Added.
    * Source/WebKit/NetworkProcess/webrtc/NetworkRTCProvider.cpp:
    (WebKit::isEmptyRTCAddress):
    (WebKit::NetworkRTCProvider::sendToSocket):
    (WebKit::NetworkRTCProvider::createUDPSocket):
    (WebKit::NetworkRTCProvider::createClientTCPSocket):

    Canonical link: https://commits.webkit.org/314720@main

Canonical link: https://commits.webkit.org/305877.732@webkitglib/2.52


  Commit: 5b474b1ff216ce9abe696f8b5cfb7b340f4cfcf4
      
https://github.com/WebKit/WebKit/commit/5b474b1ff216ce9abe696f8b5cfb7b340f4cfcf4
  Author: Philippe Normand <[email protected]>
  Date:   2026-06-12 (Fri, 12 Jun 2026)

  Changed paths:
    M 
Source/WebCore/platform/graphics/gstreamer/InbandTextTrackPrivateGStreamer.h
    M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp

  Log Message:
  -----------
  Cherry-pick 314703@main (f23d4df64f2e). 
https://bugs.webkit.org/show_bug.cgi?id=316195

    [GStreamer] ASSERTION FAILED: track->streamId() == streamId
    https://bugs.webkit.org/show_bug.cgi?id=316195

    Reviewed by Xabier Rodriguez-Calvar.

    Pass the track ID to the track constructor. Both Audio and Video track 
implementations had a
    matching create function already, but InbandTextTrack didn't, so the 
existing function was adapted
    accordingly.

    This is a prospective fix for a flaky crash that happened once on the bots. 
The results.w.o timeline
    shows no crash for this test...

    * LayoutTests/platform/glib/TestExpectations:
    * 
Source/WebCore/platform/graphics/gstreamer/InbandTextTrackPrivateGStreamer.h:
    (WebCore::InbandTextTrackPrivateGStreamer::create):
    * 
Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
    (WebCore::MediaPlayerPrivateGStreamer::notifyPlayerOfTrack):

    Canonical link: https://commits.webkit.org/314703@main

Canonical link: https://commits.webkit.org/305877.733@webkitglib/2.52


  Commit: 40bc25a4304d86de77135ab48fd1d01e550e2943
      
https://github.com/WebKit/WebKit/commit/40bc25a4304d86de77135ab48fd1d01e550e2943
  Author: Devin Rousso <[email protected]>
  Date:   2026-06-12 (Fri, 12 Jun 2026)

  Changed paths:
    M 
LayoutTests/http/tests/websocket/tests/hybi/inspector/before-load-expected.txt
    M LayoutTests/http/tests/websocket/tests/hybi/inspector/before-load.html
    M Source/WebCore/Modules/websockets/WebSocketHandshake.cpp

  Log Message:
  -----------
  Cherry-pick 314637@main (64ba9cf9f889). 
https://bugs.webkit.org/show_bug.cgi?id=316266

    [curl] REGRESSION(276696@main): Web Inspector: WebSocket response status 
text is one character short
    https://bugs.webkit.org/show_bug.cgi?id=316266

    Reviewed by Don Olmstead.

    276696@main should've used `lineLength` instead of `index` to match the 
same logic as before

    `index` points to the `\n` so subtracting one from that will miss a 
character since `std::span::subspan` will not include the item at `offset + 
count`

    * Source/WebCore/Modules/websockets/WebSocketHandshake.cpp:
    (WebCore::WebSocketHandshake::readStatusLine):

    * LayoutTests/http/tests/websocket/tests/hybi/inspector/before-load.html:
    * 
LayoutTests/http/tests/websocket/tests/hybi/inspector/before-load-expected.txt:

    Canonical link: https://commits.webkit.org/314637@main

Canonical link: https://commits.webkit.org/305877.734@webkitglib/2.52


  Commit: 7de36a77877a230d37b59d62c0d346662dc65bc9
      
https://github.com/WebKit/WebKit/commit/7de36a77877a230d37b59d62c0d346662dc65bc9
  Author: Claudio Saavedra <[email protected]>
  Date:   2026-06-12 (Fri, 12 Jun 2026)

  Changed paths:
    A 
LayoutTests/fast/scrolling/scroll-clamp-during-layout-with-pending-async-scroll-crash-expected.txt
    A 
LayoutTests/fast/scrolling/scroll-clamp-during-layout-with-pending-async-scroll-crash.html
    M Source/WebCore/platform/ScrollView.cpp

  Log Message:
  -----------
  Cherry-pick 314619@main (20aa31cf4f7e). 
https://bugs.webkit.org/show_bug.cgi?id=250907

    ASSERTION FAILED: !m_deferredScrollDelta platform/ScrollView.cpp(504) : 
virtual void WebCore::ScrollView::scrollTo(const WebCore::ScrollPosition &)
    https://bugs.webkit.org/show_bug.cgi?id=250907

    Reviewed by Simon Fraser.

    scrollTo() defers updates during layout into a single-shot 
m_deferredScrollDelta,
    asserting nothing is already pending. But 
AsyncScrollingCoordinator::applyScrollUpdate()
    drains queued scrolling-thread updates before applying its own, and both 
passes re-enter
    scrollTo() via reconcileScrollingState(): the first defers, the second 
asserts. The
    assertion is wrong because a delta can legitimately already be pending; in 
release the
    second assignment silently overwrites the first, leaving layers at a bad 
offset.

    Coalesce by summing instead, matching scrollContents()'s cumulative-delta 
semantics and
    the sibling m_deferredScrollOffsets handling.

    Reachable wherever a layout is forced mid-pending-scroll: fullscreen enter, 
pinch-zoom
    (commitTransientZoom), or a layout-flushing DOM read like offsetWidth.

    * 
LayoutTests/fast/scrolling/scroll-clamp-during-layout-with-pending-async-scroll-crash-expected.txt:
 Added.
    * 
LayoutTests/fast/scrolling/scroll-clamp-during-layout-with-pending-async-scroll-crash.html:
 Added.
    * Source/WebCore/platform/ScrollView.cpp:
    (WebCore::ScrollView::scrollTo):

    Canonical link: https://commits.webkit.org/314619@main

Canonical link: https://commits.webkit.org/305877.735@webkitglib/2.52


  Commit: abc1a4cc76ce8858ae4639c4fb181d0396f8a3ad
      
https://github.com/WebKit/WebKit/commit/abc1a4cc76ce8858ae4639c4fb181d0396f8a3ad
  Author: Alex Christensen <[email protected]>
  Date:   2026-06-12 (Fri, 12 Jun 2026)

  Changed paths:
    A 
LayoutTests/http/tests/security/model-element/exit-immersive-by-navigating-iframe-expected.txt
    A 
LayoutTests/http/tests/security/model-element/exit-immersive-by-navigating-iframe.html
    A LayoutTests/http/tests/security/model-element/resources/first-iframe.html
    A LayoutTests/http/tests/security/model-element/resources/second-iframe.html
    M Source/WebKit/WebProcess/WebPage/WebPage.cpp

  Log Message:
  -----------
  Cherry-pick 314615@main (6a4511bc5935). 
https://bugs.webkit.org/show_bug.cgi?id=316349

    Add missing null check in WebPage::exitImmersive
    https://bugs.webkit.org/show_bug.cgi?id=316349
    rdar://177184545

    Reviewed by Aditya Keerthi.

    The if statement with initializer didn't null check localTopDocument.

    * 
LayoutTests/http/tests/security/model-element/exit-immersive-by-navigating-iframe-expected.txt:
 Added.
    * 
LayoutTests/http/tests/security/model-element/exit-immersive-by-navigating-iframe.html:
 Added.
    * 
LayoutTests/http/tests/security/model-element/resources/first-iframe.html: 
Added.
    * 
LayoutTests/http/tests/security/model-element/resources/second-iframe.html: 
Added.
    * Source/WebKit/WebProcess/WebPage/WebPage.cpp:
    (WebKit::WebPage::exitImmersive):

    Canonical link: https://commits.webkit.org/314615@main

Canonical link: https://commits.webkit.org/305877.736@webkitglib/2.52


  Commit: 2f30eb95e94595607a960c12806afcfeff7ec5c9
      
https://github.com/WebKit/WebKit/commit/2f30eb95e94595607a960c12806afcfeff7ec5c9
  Author: Chris Dumez <[email protected]>
  Date:   2026-06-12 (Fri, 12 Jun 2026)

  Changed paths:
    M Source/WebCore/platform/graphics/MIMESniffer.cpp
    M Tools/TestWebKitAPI/Tests/WebCore/MIMESniffer.cpp

  Log Message:
  -----------
  Cherry-pick 314498@main (1c9e3e8e8bcd). 
https://bugs.webkit.org/show_bug.cgi?id=316181

    Out-of-bounds read in WebM MIME sniffer when iter reaches length()
    https://bugs.webkit.org/show_bug.cgi?id=316181

    Reviewed by Jean-Yves Avenard.

    In hasSignatureForWebM(), the inner skip-NUL loop reads sequence[iter]
    before testing iter < length:
    ```
          while (!sequence[iter] && iter < length)
              iter++;
    ```
    After the preceding parseWebMVint() call and the iter += numberSize
    update, iter can equal length, in which case the left operand of && is
    evaluated first and reads one byte past the end of the span. A 7-byte
    input crafted as EBML magic + 0x42 0x82 + a 1-byte vint reaches this
    code path. WebKit builds with hardened libc++, so std::span's bounds
    check turns this into a safe crash on every build, but it's still a
    reachable crash on attacker-controlled input.

    Swap the operands so the bounds check short-circuits the dereference,
    and add an API test that exercises the truncated input.

    Test: MIMESniffer.WebMSnifferDoesNotReadPastEnd

    * Source/WebCore/platform/graphics/MIMESniffer.cpp:
    (WebCore::MIMESniffer::hasSignatureForWebM):
    * Tools/TestWebKitAPI/Tests/WebCore/MIMESniffer.cpp:
    (TestWebKitAPI::TEST(MIMESniffer, WebMSnifferDoesNotReadPastEnd)):

    Canonical link: https://commits.webkit.org/314498@main

Canonical link: https://commits.webkit.org/305877.737@webkitglib/2.52


  Commit: 76416e201310554fea899a6b28777f31aba54372
      
https://github.com/WebKit/WebKit/commit/76416e201310554fea899a6b28777f31aba54372
  Author: Chris Dumez <[email protected]>
  Date:   2026-06-12 (Fri, 12 Jun 2026)

  Changed paths:
    M Source/WebCore/platform/graphics/MIMESniffer.cpp
    M Tools/TestWebKitAPI/Tests/WebCore/MIMESniffer.cpp

  Log Message:
  -----------
  Cherry-pick 314499@main (aac4f9e2bfe2). 
https://bugs.webkit.org/show_bug.cgi?id=316178

    MIDI and AVI MIME signatures are never matched due to typo in MIMESniffer
    https://bugs.webkit.org/show_bug.cgi?id=316178

    Reviewed by Jean-Yves Avenard.

    The MIDI and AVI signature literals in the MIME sniffer's pattern table 
start
    with "\0x..." rather than "\x...". The "\0" is parsed as an octal NUL escape
    and the "x" is a literal character, producing 11- and 12-byte patterns that
    begin with NUL+'x'+'4'+'D'+... and NUL+'x'+'5'+'2'+... instead of the
    intended "MThd" and "RIFF" prefixes. The associated mask is 8 bytes (MIDI)
    and 12 bytes (AVI), and since the matching loop skips any row where
    mask.size() != pattern.size(), both rows are silently dropped on every
    invocation. As a result, getMIMETypeFromContent() returns the empty string
    for valid MIDI and AVI input.

    Fix the typos by removing the leading "\0" so the patterns match their
    intended bytes, and add API test coverage for both formats.

    Test: Tools/TestWebKitAPI/Tests/WebCore/MIMESniffer.cpp

    * Source/WebCore/platform/graphics/MIMESniffer.cpp:
    (WebCore::MIMESniffer::mimeTypeFromSnifferEntries):
    * Tools/TestWebKitAPI/Tests/WebCore/MIMESniffer.cpp:
    (TestWebKitAPI::TEST(MIMESniffer, MIMETypes)):

    Canonical link: https://commits.webkit.org/314499@main

Canonical link: https://commits.webkit.org/305877.738@webkitglib/2.52


  Commit: 0137d06b4270fd6124976c45dd8db1f723c180ac
      
https://github.com/WebKit/WebKit/commit/0137d06b4270fd6124976c45dd8db1f723c180ac
  Author: Per Arne Vollan <[email protected]>
  Date:   2026-06-12 (Fri, 12 Jun 2026)

  Changed paths:
    M Source/WebKit/UIProcess/WebPageProxy.cpp

  Log Message:
  -----------
  Cherry-pick 314838@main (8d00a4139879). 
https://bugs.webkit.org/show_bug.cgi?id=316686

    Fix null pointer dereference in WebPageProxy::updateActivityState
    https://bugs.webkit.org/show_bug.cgi?id=316686
    rdar://177093411

    Reviewed by Sihui Liu.

    We should check that the page client is not null in 
WebPageProxy::updateActivityState.

    * Source/WebKit/UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::updateActivityState):

    Canonical link: https://commits.webkit.org/314838@main

Canonical link: https://commits.webkit.org/305877.739@webkitglib/2.52


Compare: https://github.com/WebKit/WebKit/compare/e3e70dd80139...0137d06b4270

To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

Reply via email to