Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 6956d905e7f0b78b1f222c2b9dec2d83fce0be52
https://github.com/WebKit/WebKit/commit/6956d905e7f0b78b1f222c2b9dec2d83fce0be52
Author: Zak Ridouh <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
A
LayoutTests/storage/indexeddb/index-cursor-reverse-delete-next-higher-key-private-expected.txt
A
LayoutTests/storage/indexeddb/index-cursor-reverse-delete-next-higher-key-private.html
M Source/WebCore/Modules/indexeddb/server/MemoryIndexCursor.cpp
Log Message:
-----------
Cherry-pick d14d12e915f3. https://bugs.webkit.org/show_bug.cgi?id=313818
[CoreIPC] [NP] Heap UAF in WebCore::IDBServer::MemoryIndexCursor reverse
iterator when a Prev/Prevunique cursor's next-higher index entry is deleted
<https://bugs.webkit.org/show_bug.cgi?id=313818>
<rdar://174678764>
Reviewed by Sihui Liu.
MemoryIndexCursor caches an IndexValueStore::Iterator across IPC messages.
For Prev/Prevunique cursors this wraps std::set<IDBKeyData>::reverse_iterator
objects (one for the outer IndexValueStore::m_orderedKeys set, one nested in
IndexValueEntry::Iterator for the inner per-index-key set). A
std::reverse_iterator stores a forward base() iterator pointing one element
past the logical position; for libc++ std::set that is a raw __tree_node*.
MemoryIndexCursor::indexValueChanged() only invalidates m_currentIterator
when the changed (key, primaryKey) equals the cursor's current logical
position. Deleting the next-higher index key (Variant A, outer set) or the
next-higher primary key under a shared index key (Variant B, inner set)
therefore frees exactly the __tree_node base() references while the guard
early-returns. The next IterateCursor IPC executes ++m_reverseIterator =>
--base() => __tree_prev_iter(freed_node), a heap-use-after-free in
com.apple.WebKit.Networking reachable from a compromised WebContent process
via NetworkStorageManager IPC with WCP-controlled
IDBDatabaseIdentifier.m_isTransient = true forcing MemoryIDBBackingStore.
Fix by gating the equality early-return on info().isDirectionForward(). For
reverse cursors we now invalidate m_currentIterator on any index mutation;
iterate() already re-seeks via reverseFind(m_currentKey, m_currentPrimaryKey)
when the iterator is invalid. Both removeEntriesWithValueKey() erase paths
(outer m_orderedKeys.erase() and inner IndexValueEntry::removeKey()) reach
indexValueChanged() through MemoryIndex::notifyCursorsOfValueChange(), so
both variants are closed.
*
LayoutTests/storage/indexeddb/index-cursor-reverse-delete-next-higher-key-private-expected.txt:
Added.
*
LayoutTests/storage/indexeddb/index-cursor-reverse-delete-next-higher-key-private.html:
Added.
* Source/WebCore/Modules/indexeddb/server/MemoryIndexCursor.cpp:
(WebCore::IDBServer::MemoryIndexCursor::indexValueChanged):
Identifier: 305413.842@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.876@webkitglib/2.52
Commit: 5936fdec6d8d7c1c2ac043ac551ac956b0a0715f
https://github.com/WebKit/WebKit/commit/5936fdec6d8d7c1c2ac043ac551ac956b0a0715f
Author: Simon Lewis <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
A LayoutTests/fast/webcodecs/audio-data-close-during-gc-crash-expected.txt
A LayoutTests/fast/webcodecs/audio-data-close-during-gc-crash.html
M Source/WebCore/Modules/webcodecs/WebCodecsAudioData.cpp
M Source/WebCore/Modules/webcodecs/WebCodecsAudioData.h
Log Message:
-----------
Cherry-pick 2102c1dad1d3. https://bugs.webkit.org/show_bug.cgi?id=313818
use-after-free in WebCodecsAudioData::memoryCost() via concurrent GC marker /
close()
rdar://175520011
Reviewed by Jean-Yves Avenard
WebCodecsAudioData is annotated with ReportExtraMemoryCost, so the generated
JS wrapper's visitChildren calls WebCodecsAudioData::memoryCost() from a
concurrent GC marker thread. memoryCost() dereferenced m_data.audioData (a
RefPtr<PlatformRawAudioData>) without synchronization while close() on the
main thread assigns m_data.audioData = nullptr and frees the
PlatformRawAudioData, leading to a heap-use-after-free in
PlatformRawAudioDataCocoa::memoryCost().
Cache the memory cost in a std::atomic<size_t> on WebCodecsAudioData,
computed once at construction time on the main thread and zeroed in close(),
so the GC-thread memoryCost() never touches the RefPtr. This matches the
existing pattern in ImageBitmap.
* LayoutTests/fast/webcodecs/audio-data-close-during-gc-crash-expected.txt:
Added.
* LayoutTests/fast/webcodecs/audio-data-close-during-gc-crash.html: Added.
* Source/WebCore/Modules/webcodecs/WebCodecsAudioData.cpp:
(WebCore::WebCodecsAudioData::WebCodecsAudioData):
(WebCore::WebCodecsAudioData::close):
* Source/WebCore/Modules/webcodecs/WebCodecsAudioData.h:
(WebCore::WebCodecsAudioData::memoryCost const):
Identifier: 305413.845@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.877@webkitglib/2.52
Commit: b20421a9f2fce56620697f0dada4168eddc691c8
https://github.com/WebKit/WebKit/commit/b20421a9f2fce56620697f0dada4168eddc691c8
Author: Said Abou-Hallawa <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
M Source/WebCore/svg/SVGGeometryElement.cpp
M Source/WebCore/svg/SVGGeometryElement.h
Log Message:
-----------
Cherry-pick d1e59347508c. https://bugs.webkit.org/show_bug.cgi?id=314326
Use-after-free in SVGGeometryElement::getPointAtLength — raw renderer pointer
held across nested updateLayout
https://bugs.webkit.org/show_bug.cgi?id=314326
rdar://175670940
Reviewed by Simon Fraser.
Between the call to `updateLayoutIgnorePendingStylesheets()` and the call to
`SVGGeometryElement::getTotalLength()`, `SVGGeometryElement::getPointAtLength()`
caches its renderer() in a raw pointer. The problem is `getTotalLength()` also
calls `updateLayoutIgnorePendingStylesheets()` which may delete the renderer.
This will make `getPointAtLength()` use-after-free the cached raw pointer
renderer.
Rearrange the code such that `updateLayoutIgnorePendingStylesheets()` is called
only once per `getPointAtLength()` and read `this->renderer()` exactly before it
is referenced.
* Source/WebCore/svg/SVGGeometryElement.cpp:
(WebCore::SVGGeometryElement::calculateTotalLength const):
(WebCore::SVGGeometryElement::getTotalLength const):
(WebCore::SVGGeometryElement::calculatePointAtLength const):
(WebCore::SVGGeometryElement::getPointAtLength const):
* Source/WebCore/svg/SVGGeometryElement.h:
Identifier: 305413.857@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.878@webkitglib/2.52
Commit: 2740ab9e70126f8328b7d26cd448233234078a70
https://github.com/WebKit/WebKit/commit/2740ab9e70126f8328b7d26cd448233234078a70
Author: Vassili Bykov <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
A JSTests/wasm/gc/transitive-type-retention-global.js
A JSTests/wasm/gc/transitive-type-retention-table.js
M Source/JavaScriptCore/wasm/WasmGlobal.h
M Source/JavaScriptCore/wasm/WasmTable.cpp
M Source/JavaScriptCore/wasm/WasmTable.h
Log Message:
-----------
Cherry-pick 8678798b3372. https://bugs.webkit.org/show_bug.cgi?id=314235
[JSC] Wasm Table and Global Missing Transitive TypeDefinition Retention
https://bugs.webkit.org/show_bug.cgi?id=314235
rdar://176031363
Reviewed by Keith Miller.
Wasm::Global and Wasm::Table retain the immediate TypeDefinition behind
their m_wasmType, but not type definitions transitively reachable from it.
They should use WebAssemblyGCTypeDependencies instead to retain the entire
transitive closure of reachable TypeDefinitions, as Wasm::Tag does.
Tests: JSTests/wasm/gc/transitive-type-retention-global.js
JSTests/wasm/gc/transitive-type-retention-table.js
Identifier: 305413.859@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.879@webkitglib/2.52
Commit: a6041eced9df75d84ef218994288ecce0107793e
https://github.com/WebKit/WebKit/commit/a6041eced9df75d84ef218994288ecce0107793e
Author: Said Abou-Hallawa <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
M
Source/WebCore/platform/graphics/filters/software/FilterEffectSoftwareParallelApplier.h
Log Message:
-----------
Cherry-pick 5d5fdc06de11. https://bugs.webkit.org/show_bug.cgi?id=314268
REGRESSION(305413.516@safari-7624-branch): The height of the FEMorphology
filter might be off by 1
https://bugs.webkit.org/show_bug.cgi?id=314268
rdar://175674532
Reviewed by Simon Fraser.
In https://commits.webkit.org/305413.516@safari-7624-branch, ParallelJobs are
used to apply the FEMorphology filter. Applying the filter in parallel happens
in two steps:
1. Split the destination pixel buffer into `jobs` horizontal strips and then
dispatches them in parallel
2. When all the parallel jobs finish, the scratch outputs are stitched back via
a gather loop.
The first job is done directly into the destination PixelBuffer. So no stitching
is needed for job_0. Stitching the rest of the jobs (job_1 .. job_{n-1})
requires
moving the y-position in destination PixelBuffer by the height of the previous
job. And it requires also calculating the height of the current job. The problem
is the height of the current job is used to move y-position. This may prevent
stitching the last line in the last job to the destination PixelBuffer.
*
Source/WebCore/platform/graphics/filters/software/FilterEffectSoftwareParallelApplier.h:
(WebCore::applyPlatformParallel):
Identifier: 305413.865@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.880@webkitglib/2.52
Commit: a093baf503690c93baaf3b5fd3f390d2aaf2f4da
https://github.com/WebKit/WebKit/commit/a093baf503690c93baaf3b5fd3f390d2aaf2f4da
Author: Chris Dumez <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
A LayoutTests/streams/transform-stream-poisoned-iterator-crash-expected.txt
A LayoutTests/streams/transform-stream-poisoned-iterator-crash.html
M Source/WebCore/Modules/streams/TransformStream.cpp
Log Message:
-----------
Cherry-pick cb2c361c977a. https://bugs.webkit.org/show_bug.cgi?id=314528
[WebCore] TransformStream type confusion when Array.prototype[Symbol.iterator]
is overridden
https://bugs.webkit.org/show_bug.cgi?id=314528
rdar://176568667
Reviewed by Ryosuke Niwa.
createInternalTransformStream invokes the
createInternalTransformStreamFromTransformer
builtin and converts its result via convert<IDLSequence<IDLObject>>, which uses
the JS iteration protocol. If a page overrides Array.prototype[Symbol.iterator],
it can substitute arbitrary objects for the readable/writable entries the
builtin would otherwise return. The only guard was ASSERT(results.size() == 3),
which is a no-op in release, after which jsDynamicCast<JSReadableStream*> /
jsDynamicCast<JSWritableStream*> were dereferenced unconditionally — turning a
non-matching object into a controlled type confusion (controlled deref via
m_wrapped, write-increment via Ref<>::ref(), and a vtable call on attacker
data when JS later touches .readable / .writable).
Replace the ASSERT with a runtime size check, null-check the jsDynamicCast
results, and throw a TypeError on either failure.
Test: streams/transform-stream-poisoned-iterator-crash.html
* LayoutTests/streams/transform-stream-poisoned-iterator-crash-expected.txt:
Added.
* LayoutTests/streams/transform-stream-poisoned-iterator-crash.html: Added.
* Source/WebCore/Modules/streams/TransformStream.cpp:
(WebCore::createInternalTransformStream):
Identifier: 305413.875@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.881@webkitglib/2.52
Commit: c3615422ed78676755339656326552197308d8b1
https://github.com/WebKit/WebKit/commit/c3615422ed78676755339656326552197308d8b1
Author: Timothy Hatcher <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
M Source/WebKit/Shared/Extensions/WebExtensionSQLiteDatabase.h
Log Message:
-----------
Cherry-pick 0a9952c703a7. https://bugs.webkit.org/show_bug.cgi?id=314569
Use-after-free in WebExtensionSQLiteDatabase via cross-thread non-atomic
RefCounted race.
https://webkit.org/b/314569
rdar://176483124
Reviewed by Abrar Rahman Protyasha.
WebExtensionSQLiteDatabase used a non-atomic RefCounted base despite its
refcount being accessed
concurrently from both the WKWebExtensionSQLiteStore WorkQueue and the UI main
thread, so
concurrent ref/deref operations could corrupt the count and cause a premature
free.
* Source/WebKit/Shared/Extensions/WebExtensionSQLiteDatabase.h: Use
ThreadSafeRefCounted.
Identifier: 305413.879@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.882@webkitglib/2.52
Commit: c4549075345945ceb1ca976cd1f2922aa5905148
https://github.com/WebKit/WebKit/commit/c4549075345945ceb1ca976cd1f2922aa5905148
Author: Zak Ridouh <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
A LayoutTests/ipc/nested-display-list-draw-control-part-crash-expected.txt
A LayoutTests/ipc/nested-display-list-draw-control-part-crash.html
M Source/WebCore/platform/graphics/displaylists/DisplayListItem.cpp
M Source/WebCore/platform/graphics/displaylists/DisplayListItems.cpp
M Source/WebCore/platform/graphics/displaylists/DisplayListItems.h
Log Message:
-----------
Cherry-pick 28d3cd063035. https://bugs.webkit.org/show_bug.cgi?id=314581
[CoreIPC] [GPUP] Nested DrawDisplayList Replay Falls Back to
ControlFactory::singleton() Leads to Concurrent NSCell UAF
<https://bugs.webkit.org/show_bug.cgi?id=314581>
<rdar://174674075>
Reviewed by Simon Fraser.
DisplayList::applyItem() only special-cases DrawControlPart, so a nested
DrawDisplayList item falls through to item.apply(context) and calls the
single-arg GraphicsContext::drawDisplayList, which substitutes
ControlFactory::singleton(). A compromised WCP can wrap DrawControlPart
items in a nested DrawDisplayList and replay it on multiple
RemoteRenderingBackends, racing the singleton ControlFactoryMac's shared
NSCell state across GPU-process work-queue threads.
Thread ControlFactory through DrawDisplayList::apply() and special-case
DrawDisplayList in applyItem() so nested replay uses the per-context
factory.
* LayoutTests/ipc/nested-display-list-draw-control-part-crash-expected.txt:
Added.
* LayoutTests/ipc/nested-display-list-draw-control-part-crash.html: Added.
* Source/WebCore/platform/graphics/displaylists/DisplayListItem.cpp:
(WebCore::DisplayList::applyItem):
* Source/WebCore/platform/graphics/displaylists/DisplayListItems.cpp:
(WebCore::DisplayList::DrawDisplayList::apply const):
* Source/WebCore/platform/graphics/displaylists/DisplayListItems.h:
Identifier: 305413.904@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.883@webkitglib/2.52
Commit: 1626efd119bf3e66be3122932b4d1412af665904
https://github.com/WebKit/WebKit/commit/1626efd119bf3e66be3122932b4d1412af665904
Author: Chris Dumez <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
M
LayoutTests/editing/async-clipboard/clipboard-change-data-while-getting-type.html
M LayoutTests/editing/async-clipboard/clipboard-get-type-with-old-items.html
M LayoutTests/editing/async-clipboard/resources/async-clipboard-helpers.js
A
LayoutTests/http/tests/security/clipboard/clipboard-access-in-cross-origin-iframe-denied-expected.txt
A
LayoutTests/http/tests/security/clipboard/clipboard-access-in-cross-origin-iframe-denied.html
A
LayoutTests/http/tests/security/clipboard/resources/clipboard-access-from-iframe.html
M
LayoutTests/imported/w3c/web-platform-tests/clipboard-apis/async-navigator-clipboard-basics.https-expected.txt
M
LayoutTests/imported/w3c/web-platform-tests/clipboard-apis/async-navigator-clipboard-basics.https.html
M
LayoutTests/imported/w3c/web-platform-tests/clipboard-apis/resources/user-activation.js
M Source/WebCore/Modules/async-clipboard/Clipboard.cpp
Log Message:
-----------
Cherry-pick 526ac3579021. https://bugs.webkit.org/show_bug.cgi?id=314806
Cross-Origin Iframe Can Read Clipboard via Top-Level User Interaction in Safari
https://bugs.webkit.org/show_bug.cgi?id=314806
rdar://176023893
Reviewed by Ryosuke Niwa.
navigator.clipboard.readText(), read(), writeText(), and write() relied on
WebKit's
legacy UserGestureIndicator for activation checks (directly for writes, via
LocalFrame::requestDOMPasteAccess() for reads).
LocalDOMWindow::processPostMessage
explicitly forwards the active UserGestureToken into the receiving iframe's
event
handler, so a user click on a top-level page let a cross-origin iframe see
"processing
a user gesture" and access the clipboard. This violates the W3C Clipboard API
spec,
which requires transient activation on the relevant global object.
Fix this by checking LocalDOMWindow::hasTransientActivation() at the entry
point of
each clipboard method. Transient activation is a property of the window and only
propagates to ancestor frames and same-origin descendant frames -- it is never
propagated to cross-origin descendants via postMessage. This matches the
behavior of
Blink and Firefox.
Test:
http/tests/security/clipboard/clipboard-access-in-cross-origin-iframe-denied.html
*
LayoutTests/editing/async-clipboard/clipboard-change-data-while-getting-type.html:
* LayoutTests/editing/async-clipboard/clipboard-get-type-with-old-items.html:
* LayoutTests/editing/async-clipboard/resources/async-clipboard-helpers.js:
Fix existing tests so they keep passing.
*
LayoutTests/http/tests/security/clipboard/clipboard-access-in-cross-origin-iframe-denied-expected.txt:
Added.
*
LayoutTests/http/tests/security/clipboard/clipboard-access-in-cross-origin-iframe-denied.html:
Added.
*
LayoutTests/http/tests/security/clipboard/resources/clipboard-access-from-iframe.html:
Added.
New test coverage.
*
LayoutTests/imported/w3c/web-platform-tests/clipboard-apis/async-navigator-clipboard-basics.https-expected.txt:
*
LayoutTests/imported/w3c/web-platform-tests/clipboard-apis/async-navigator-clipboard-basics.https.html:
*
LayoutTests/imported/w3c/web-platform-tests/clipboard-apis/resources/user-activation.js:
Resync existing WPT test so it keeps passing.
* Source/WebCore/Modules/async-clipboard/Clipboard.cpp:
(WebCore::frameHasTransientActivation):
(WebCore::shouldProceedWithClipboardWrite):
(WebCore::Clipboard::readText):
(WebCore::Clipboard::read):
Identifier: 305413.908@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.884@webkitglib/2.52
Commit: da427f199f92b9448c4f7dbade8e965255c30cab
https://github.com/WebKit/WebKit/commit/da427f199f92b9448c4f7dbade8e965255c30cab
Author: Vassili Bykov <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
A JSTests/stress/arguments-elimination-multiple-inline-call-frames.js
M Source/JavaScriptCore/dfg/DFGArgumentsEliminationPhase.cpp
Log Message:
-----------
Cherry-pick 3270ebdb7366. https://bugs.webkit.org/show_bug.cgi?id=314850
[JSC] DFGArgumentsEliminationPhase removeViaKill should reset node scan index
between InlineCallFrames
https://bugs.webkit.org/show_bug.cgi?id=314850
rdar://176966728
Reviewed by Yusuke Suzuki.
In DFGArgumentsEliminationPhase::eliminateCandidatesThatInterfere(), the
removeViaKill
lambda contains two nested loops. The outer loop iterates over inline call
frames. For
each frame, the inner loop is expected to iterate the nodes of the given basic
block in
reverse order in the range [0, nodeIndex). However, because the inner loop
mutates the
lambda parameter nodeIndex directly, this only works as intended for the first
inline call
frame. Each subsequent call frame begins where the previous one left off.
The change introduces a separate iteration variable for the inner loop, which
starts off
at nodeIndex for each inline call frame. nodeIndex parameter is marked as
'const' to make
explicit the expectation that it should not change.
Test: JSTests/stress/arguments-elimination-multiple-inline-call-frames.js
Identifier: 305413.912@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.885@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/f09ffa51faf4...da427f199f92
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
