Branch: refs/heads/webkitglib/2.54
Home: https://github.com/WebKit/WebKit
Commit: 6ba9267c21f14d2dd567907718e9149e028f7558
https://github.com/WebKit/WebKit/commit/6ba9267c21f14d2dd567907718e9149e028f7558
Author: Dan Hecht <[email protected]>
Date: 2026-09-15 (Tue, 15 Sep 2026)
Changed paths:
M Source/bmalloc/libpas/src/libpas/pas_page_malloc.c
Log Message:
-----------
Cherry-pick 316606.169@safari-7625-branch (970accdcb0d7).
https://bugs.webkit.org/show_bug.cgi?id=319987
[libpas] Use mmap zeroing rather than madvise when MTE is disabled
https://bugs.webkit.org/show_bug.cgi?id=319987
rdar://176518186
Reviewed by Keith Miller.
For now, let's use mmap for the large VA zeroing path rather than
madvise. But when MTE is enabled, continue using madvise since the
tag status is unknown.
* Source/bmalloc/libpas/src/libpas/pas_page_malloc.c:
(pas_page_malloc_zero_fill_latch_if_madv_zero_is_supported):
Identifier: 316606.169@safari-7625-branch
Canonical link: https://commits.webkit.org/317695.321@webkitglib/2.54
Commit: b52725a1714b6af2986f761c800c0a6c6013d1c6
https://github.com/WebKit/WebKit/commit/b52725a1714b6af2986f761c800c0a6c6013d1c6
Author: Alan Baradlay <[email protected]>
Date: 2026-09-15 (Tue, 15 Sep 2026)
Changed paths:
A LayoutTests/fast/canvas/canvas-layer-after-max-save-count-expected.txt
A LayoutTests/fast/canvas/canvas-layer-after-max-save-count.html
M Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp
Log Message:
-----------
Cherry-pick c5a2b165a95e. https://bugs.webkit.org/show_bug.cgi?id=318378
Use-after-free in CanvasRenderingContext2DBase::beginLayer via
realizeSavesLoop early exit
https://bugs.webkit.org/show_bug.cgi?id=318378
<rdar://175228541>
Reviewed by Said Abou-Hallawa.
beginLayer() relies on realizeSaves() pushing a fresh State onto
m_stateStack so that the new layer's CanvasLayerContextSwitcher is stored
in its own frame. If the state stack is already at MaxSaveCount,
realizeSavesLoop() returns without growing the stack and
m_unrealizedSaveCount remains nonzero. Creating a layer in that case
would overwrite the targetSwitcher of the current top State, dropping the
previous layer while the new layer still holds a raw pointer to the
previous layer's GraphicsContext, leading to a use-after-free.
Fix this by returning early from beginLayer() when realizeSaves() was
unable to push a new State (m_unrealizedSaveCount is still nonzero).
Test: fast/canvas/canvas-layer-after-max-save-count.html
* LayoutTests/fast/canvas/canvas-layer-after-max-save-count-expected.txt:
Added.
* LayoutTests/fast/canvas/canvas-layer-after-max-save-count.html: Added.
* Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp:
(WebCore::CanvasRenderingContext2DBase::beginLayer):
Identifier: [email protected]
Identifier: 316606.203@safari-7625-branch
Canonical link: https://commits.webkit.org/317695.322@webkitglib/2.54
Commit: 3a8c958803ac37d2de7fbf5b2b3fac44ec8523fa
https://github.com/WebKit/WebKit/commit/3a8c958803ac37d2de7fbf5b2b3fac44ec8523fa
Author: David Kilzer <[email protected]>
Date: 2026-09-15 (Tue, 15 Sep 2026)
Changed paths:
M Source/WebCore/page/Page.cpp
Log Message:
-----------
Cherry-pick 316606.223@safari-7625-branch (674ff0d01ca3).
https://bugs.webkit.org/show_bug.cgi?id=320100
WebCore::Page::forEachPage should iterate a snapshot of allPages()
<https://bugs.webkit.org/show_bug.cgi?id=320100>
<rdar://179997790>
Reviewed by Chris Dumez.
Iterate a snapshot of the global page registry so a callback that
mutates the registry cannot invalidate the iterator. `forEachPage`
walked the live `allPages()` hash set while invoking an arbitrary
caller callback per page. A callback that synchronously creates or
destroys a `Page` mutates `allPages()` (through the constructor's
`add()` and the destructor's `remove()`), which can rehash the set and
free the bucket array the iterator is still walking, leaving the loop
dereferencing freed memory.
Build a `Vector<Ref<Page>>` snapshot first, matching the existing
pattern in `LocalDOMWindow::forEachWindowInterestedInStorageEvents`.
Holding a `Ref` to each page for the loop's duration also extends the
guarantee the previous per-element `Ref` temporary already gave the
current page to every page in the snapshot.
Also snapshot `allPages()` in the other methods that iterate it live
and could re-enter through their per-page work:
`clearPreviousItemFromAllPages`,
`updateStyleForAllPagesAfterGlobalChangeInEnvironment`, and
`updateControlTintsForAllPages`. `networkStateChanged` and
`refreshPlugins` already collect into a local container before acting,
so they are left unchanged.
* Source/WebCore/page/Page.cpp:
(WebCore::Page::forEachPage):
(WebCore::Page::clearPreviousItemFromAllPages):
(WebCore::Page::updateStyleForAllPagesAfterGlobalChangeInEnvironment):
(WebCore::Page::updateControlTintsForAllPages):
Identifier: 316606.223@safari-7625-branch
Canonical link: https://commits.webkit.org/317695.323@webkitglib/2.54
Commit: f7e2bdf51475248f6e204ded9c52a27cc5034b6e
https://github.com/WebKit/WebKit/commit/f7e2bdf51475248f6e204ded9c52a27cc5034b6e
Author: Chris Dumez <[email protected]>
Date: 2026-09-15 (Tue, 15 Sep 2026)
Changed paths:
M Source/WebCore/platform/audio/cocoa/CARingBuffer.h
M Source/WebKit/UIProcess/SpeechRecognitionRemoteRealtimeMediaSource.cpp
M Source/WebKit/UIProcess/SpeechRecognitionRemoteRealtimeMediaSource.h
M
Source/WebKit/UIProcess/SpeechRecognitionRemoteRealtimeMediaSourceManager.cpp
Log Message:
-----------
Cherry-pick 316606.245@safari-7625-branch (1d7dfd5f55aa).
https://bugs.webkit.org/show_bug.cgi?id=320175
Validate numberOfFrames in
SpeechRecognitionRemoteRealtimeMediaSourceManager::remoteAudioSamplesAvailable
https://bugs.webkit.org/show_bug.cgi?id=320175
rdar://183111028
Reviewed by Jean-Yves Avenard.
remoteAudioSamplesAvailable() received numberOfFrames from the (untrusted)
WebContent process and used it to size an audio buffer in the UI process
(via WebAudioBufferList::setSampleCount()), which only guards against
arithmetic overflow, not against merely-large values. A compromised
WebContent
process could therefore trigger an unbounded allocation in the UI process.
Validate the message: reject it unless the source's shared ring buffer has
been
mapped and numberOfFrames is non-zero and no larger than that buffer's
capacity.
The producing process had to actually allocate shared memory for that
capacity,
so this removes the amplification. Add CARingBuffer::frameCount() and
SpeechRecognitionRemoteRealtimeMediaSource::audioBufferFrameCount() to
expose
the bound to the message receiver.
* Source/WebCore/platform/audio/cocoa/CARingBuffer.h:
(WebCore::CARingBuffer::frameCount const):
* Source/WebKit/UIProcess/SpeechRecognitionRemoteRealtimeMediaSource.cpp:
(WebKit::SpeechRecognitionRemoteRealtimeMediaSource::audioBufferFrameCount
const):
* Source/WebKit/UIProcess/SpeechRecognitionRemoteRealtimeMediaSource.h:
*
Source/WebKit/UIProcess/SpeechRecognitionRemoteRealtimeMediaSourceManager.cpp:
(WebKit::SpeechRecognitionRemoteRealtimeMediaSourceManager::remoteAudioSamplesAvailable):
Identifier: 316606.245@safari-7625-branch
Canonical link: https://commits.webkit.org/317695.324@webkitglib/2.54
Commit: a47c50d2e5800cfa63171998f10dbbb6ba5273ab
https://github.com/WebKit/WebKit/commit/a47c50d2e5800cfa63171998f10dbbb6ba5273ab
Author: Keith Miller <[email protected]>
Date: 2026-09-15 (Tue, 15 Sep 2026)
Changed paths:
M Source/JavaScriptCore/heap/Heap.cpp
Log Message:
-----------
Cherry-pick 316606.250@safari-7625-branch (0c21be440adc).
https://bugs.webkit.org/show_bug.cgi?id=320401
finalizeWasmCalleeCleanup should run a cross-modifying code fence
https://bugs.webkit.org/show_bug.cgi?id=320401
rdar://183357733
Reviewed by Marcus Plutowski.
In theory it's possible for finalizeWasmCalleeCleanup to remove the last
reference to a BBQCallee while it's still reachable from the current
thread via a stale direct call. While I don't think this is practically
possible we might as well fence so the requirement is documented.
No new tests, theoretical bug.
Identifier: 316606.250@safari-7625-branch
Canonical link: https://commits.webkit.org/317695.325@webkitglib/2.54
Commit: 6cc49a9493278f9b59582505e60c8e3cf3178be7
https://github.com/WebKit/WebKit/commit/6cc49a9493278f9b59582505e60c8e3cf3178be7
Author: Marcos Caceres <[email protected]>
Date: 2026-09-15 (Tue, 15 Sep 2026)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/UIDelegate.mm
M Source/WebKit/UIProcess/ios/WKGeolocationProviderIOS.mm
M Tools/TestWebKitAPI/Tests/WebKit/WKWebView/Geolocation.mm
Log Message:
-----------
Cherry-pick 316606.259@safari-7625-branch (8f8dbbfd88ca).
https://bugs.webkit.org/show_bug.cgi?id=306286
Use requesting origin instead of active origin for Geolocation permission
prompt
<rdar://problem/183281228>
https://bugs.webkit.org/show_bug.cgi?id=306286
Reviewed by Chris Dumez.
The Geolocation permission prompt derived the origin it displays from the
page's active
(provisional) navigation URL rather than from the request's origin, so a
page could start a
navigation to another origin and have the prompt attribute the request to
that origin while
the requesting document kept running. Use the request's top-level origin
(frameInfo.topOrigin)
for both the WKUIDelegate prompt and the built-in iOS provider prompt,
matching the
DeviceOrientation permission prompt.
Identifier: 316606.259@safari-7625-branch
Canonical link: https://commits.webkit.org/317695.326@webkitglib/2.54
Compare: https://github.com/WebKit/WebKit/compare/ce7c6593ad44...6cc49a949327
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
