Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: ccff81d1a5490d19887a8d5506abc58327730b9f
https://github.com/WebKit/WebKit/commit/ccff81d1a5490d19887a8d5506abc58327730b9f
Author: Said Abou-Hallawa <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
M Source/WebCore/platform/graphics/cpu/arm/filters/FEBlendNeonApplier.cpp
M Source/WebCore/platform/graphics/filters/FilterImage.cpp
M Source/WebCore/platform/graphics/filters/FilterImage.h
Log Message:
-----------
Cherry-pick dbf10417aa9e. https://bugs.webkit.org/show_bug.cgi?id=314906
FilterImage may return uninitialized PixelBuffer
https://bugs.webkit.org/show_bug.cgi?id=314906
rdar://176813834
Reviewed by Darin Adler.
FilterImage provides three different representations of the image: ImageBuffer,
Unpremultiplied PixelBuffer and Premultiplied PixelBuffer. These three buffers
are lazily created. Each of them is created only when it is needed. But keep in
mind they are copies of each other. In other words, when one is created it has
to copy the pixels from the existing buffers. Otherwise it has to be
zero-filled.
A problem may happen when copying the pixels from one buffer to a newly created
buffer fails. In this case we send uninitialized PixelBuffer which may expose
user
private data. Not able to copy existing pixels to the PixelBuffer should be
treated
as an error. So a null PixelBuffer should be returned in this case.
* Source/WebCore/platform/graphics/cpu/arm/filters/FEBlendNeonApplier.cpp:
(WebCore::FEBlendNeonApplier::apply const):
* Source/WebCore/platform/graphics/filters/FilterImage.cpp:
(WebCore::copyImageBytes):
(WebCore::FilterImage::pixelBuffer):
(WebCore::FilterImage::getPixelBuffer):
(WebCore::FilterImage::copyPixelBuffer):
* Source/WebCore/platform/graphics/filters/FilterImage.h:
Identifier: 305413.919@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.887@webkitglib/2.52
Commit: 965d271f45c1e4ef886087721b20a4ed951913d9
https://github.com/WebKit/WebKit/commit/965d271f45c1e4ef886087721b20a4ed951913d9
Author: Chris Dumez <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
M Source/WebKit/UIProcess/WebFrameProxy.cpp
Log Message:
-----------
Cherry-pick 332b0cbb0bb4. https://bugs.webkit.org/show_bug.cgi?id=315006
Missing validation of frameInfo in WebFrameProxy::getFrameInfo()
https://bugs.webkit.org/show_bug.cgi?id=315006
rdar://176816153
Reviewed by Ryosuke Niwa.
Harden WebFrameProxy::getFrameInfo() so the security-relevant fields of
the FrameInfoData struct returned by WebProcess are now validated.
In case of mismatch, we overwrite with correct values and log an error
message instead of doing a MESSAGE_CHECK, to reduce risk.
* Source/WebKit/UIProcess/WebFrameProxy.cpp:
(WebKit::WebFrameProxy::getFrameInfo):
Identifier: 305413.931@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.888@webkitglib/2.52
Commit: b5ec6fa781103e8e372a3a9318330b11df40672c
https://github.com/WebKit/WebKit/commit/b5ec6fa781103e8e372a3a9318330b11df40672c
Author: Chris Dumez <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
M Source/WebCore/bindings/js/JSTextTrackCueCustom.cpp
M Source/WebCore/html/track/InbandDataTextTrack.h
M Source/WebCore/html/track/InbandGenericTextTrack.h
M Source/WebCore/html/track/InbandTextTrack.h
M Source/WebCore/html/track/InbandWebVTTTextTrack.h
M Source/WebCore/html/track/LoadableTextTrack.h
M Source/WebCore/html/track/TextTrack.h
M Source/WebCore/html/track/TextTrackCue.cpp
M Source/WebCore/html/track/TextTrackCue.h
Log Message:
-----------
Cherry-pick 133b57500c3a. https://bugs.webkit.org/show_bug.cgi?id=314952
Data race in JSTextTrackCue::visitAdditionalChildrenInGCThread leading to
use-after-free (variant of bug 311800)
https://bugs.webkit.org/show_bug.cgi?id=314952
rdar://177248996
Reviewed by Geoffrey Garen.
JSTextTrackCue::visitAdditionalChildrenInGCThread() was accessing
`TrackTraceCue::m_track` from the GC thread, even though it is a WeakPtr
which can get nulled out on the main thread.
To address the issue:
- Turn `TrackTraceCue::m_track` into a CheckedPtr. This is OK because the
~Track() destructor takes care of nulling out its cues' m_track pointer
explicitly.
- Add a Lock to synchronize setting m_track on the main thread in
`TextTrackCue::setTrack()` and accessing it on the GC thread.
* Source/WebCore/bindings/js/JSTextTrackCueCustom.cpp:
(WebCore::JSTextTrackCue::visitAdditionalChildren):
* Source/WebCore/html/track/InbandDataTextTrack.h:
* Source/WebCore/html/track/InbandGenericTextTrack.h:
* Source/WebCore/html/track/InbandTextTrack.h:
* Source/WebCore/html/track/InbandWebVTTTextTrack.h:
* Source/WebCore/html/track/LoadableTextTrack.h:
* Source/WebCore/html/track/TextTrack.h:
* Source/WebCore/html/track/TextTrackCue.cpp:
(WebCore::TextTrackCue::willChange):
(WebCore::TextTrackCue::didChange):
(WebCore::TextTrackCue::track const):
(WebCore::TextTrackCue::protectedTrack const):
(WebCore::TextTrackCue::setTrack):
(WebCore::TextTrackCue::cueIndex const):
(WebCore::TextTrackCue::hasEquivalentStartTime const):
(WebCore::TextTrackCue::visitAdditionalChildren):
* Source/WebCore/html/track/TextTrackCue.h:
Identifier: 305413.937@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.889@webkitglib/2.52
Commit: f3c37d7ca6bd5771a3caaf4ea06da65436d4c6b8
https://github.com/WebKit/WebKit/commit/f3c37d7ca6bd5771a3caaf4ea06da65436d4c6b8
Author: Anand Srinivasan <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
A JSTests/wasm/stress/br-on-cast-reserved-flags.js
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
Log Message:
-----------
Cherry-pick 6d5ae0fc9aa1. https://bugs.webkit.org/show_bug.cgi?id=315223
WasmGC should reject reserved bits in br_on_cast/br_on_cast_fail flags byte
https://bugs.webkit.org/show_bug.cgi?id=315223
rdar://176190526
Reviewed by Dan Hecht.
In br_on_cast and br_on_cast_fail flag bits other than 0 and 1 are
reserved. The validator currently does not check that reserved bits are
0 and IPInt assumes reserved bits are 0. This patch makes the validator
check the reserved bits.
Test: JSTests/wasm/stress/br-on-cast-reserved-flags.js
* JSTests/wasm/stress/br-on-cast-reserved-flags.js: Added.
* Source/JavaScriptCore/wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
Identifier: 305413.945@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.890@webkitglib/2.52
Commit: fc7f707775c1238b9cff03898cdfe6ab22e36534
https://github.com/WebKit/WebKit/commit/fc7f707775c1238b9cff03898cdfe6ab22e36534
Author: Kai Tamkun <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
M Source/bmalloc/libpas/src/libpas/bmalloc_heap_inlines.h
M Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
A Tools/TestWebKitAPI/Tests/WTF/bmalloc/MAR.cpp
Log Message:
-----------
Cherry-pick d945beacb08e. https://bugs.webkit.org/show_bug.cgi?id=314679
[libpas] bmalloc_try_allocate_zeroed_inline calls PAS_MAR_TRACK_ALLOCATION
instead of PAS_MAR_TRACK_ALLOCATION_AND_ZERO on MAR branch, returning unzeroed
memory
rdar://175683200
https://bugs.webkit.org/show_bug.cgi?id=314679
Reviewed by Yusuke Suzuki.
This patch changes `bmalloc_try_allocate_zeroed_inline` so that it
zeroes the returned memory in the case where the MAR predicate matches.
Tests: Tools/TestWebKitAPI/Tests/WTF/bmalloc/MAR.cpp
* Source/bmalloc/libpas/src/libpas/bmalloc_heap_inlines.h:
(bmalloc_try_allocate_zeroed_inline): Zero the returned memory.
* Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* Tools/TestWebKitAPI/Tests/WTF/bmalloc/MAR.cpp: Added.
(TestWebKitAPI::pageIndexOf):
(TestWebKitAPI::testZeroedAllocationAfterPriming):
(TestWebKitAPI::TEST(bmalloc, MARZeroedAllocationWithMARDisabled)):
(TestWebKitAPI::TEST(bmalloc, MARZeroedAllocationWithMAREnabled)):
Identifier: 305413.946@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.891@webkitglib/2.52
Commit: 62ebf28b87693f9cb042c968f3c8bcdad8d27913
https://github.com/WebKit/WebKit/commit/62ebf28b87693f9cb042c968f3c8bcdad8d27913
Author: Antti Koivisto <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
A
LayoutTests/fast/custom-elements/xml-parser-reparent-during-construction-crash-expected.txt
A
LayoutTests/fast/custom-elements/xml-parser-reparent-during-construction-crash.xhtml
M Source/WebCore/xml/parser/XMLDocumentParserLibxml2.cpp
Log Message:
-----------
Cherry-pick 19beaaec03d0. https://bugs.webkit.org/show_bug.cgi?id=314679
[WebCore] use-after-free in Style::TreeResolver —
XMLDocumentParser::startElementNs missing parentNode re-check after
custom-element upgrade
rdar://177479772
Reviewed by Ryosuke Niwa.
Draining the custom element reaction stack in startElementNs runs the
constructor synchronously, which can re-parent newElement, adopt it into
another document, or detach the current parser node. parserAppendChild
requires its argument to have no parent and to share our document, so
falling through into it leaves the tree linked into two child lists.
Re-check those invariants after the reaction stack drains and stop
parsing if any of them no longer holds. A spec-aligned follow-up should
route XML element creation through constructElementWithFallback like
HTMLDocumentParser does, which post-validates and falls back to
HTMLUnknownElement; a FIXME records that.
Test: fast/custom-elements/xml-parser-reparent-during-construction-crash.xhtml
*
LayoutTests/fast/custom-elements/xml-parser-reparent-during-construction-crash-expected.txt:
Added.
*
LayoutTests/fast/custom-elements/xml-parser-reparent-during-construction-crash.xhtml:
Added.
* Source/WebCore/xml/parser/XMLDocumentParserLibxml2.cpp:
(WebCore::XMLDocumentParser::startElementNs):
Identifier: 305413.947@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.892@webkitglib/2.52
Commit: 1cd01f7eccb9f4b1662f3a76c6d9ada1572ecbd1
https://github.com/WebKit/WebKit/commit/1cd01f7eccb9f4b1662f3a76c6d9ada1572ecbd1
Author: Shu-yu Guo <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
A JSTests/wasm/gc/private-fields-and-methods.js
M Source/JavaScriptCore/runtime/JSObjectInlines.h
Log Message:
-----------
Cherry-pick 525600a227a6. https://bugs.webkit.org/show_bug.cgi?id=314438
[JSC] Disallow defining private names on WasmGC objects
https://bugs.webkit.org/show_bug.cgi?id=314438
rdar://176445615
Reviewed by Yusuke Suzuki.
While the spec currently technically allows for defining private fields and
methods on WasmGC objects, this is against the spirit of those objects being
fixed-layout.
For compat, both V8 and SpiderMonkey also disallow addition of private names on
WasmGC objects.
Test: JSTests/wasm/gc/private-fields-and-methods.js
* JSTests/wasm/gc/private-fields-and-methods.js: Added.
(testPrivateMethodOnStruct.B):
(testPrivateMethodOnStruct.D.prototype.m):
(testPrivateMethodOnStruct.D):
(testPrivateMethodOnStruct):
(testPrivateFieldOnStruct.B):
(testPrivateFieldOnStruct.D):
(testPrivateFieldOnStruct):
(testPrivateMethodOnArray.B):
(testPrivateMethodOnArray.D.prototype.m):
(testPrivateMethodOnArray.D):
(testPrivateMethodOnArray):
(testPrivateFieldOnArray.B):
(testPrivateFieldOnArray.D):
(testPrivateFieldOnArray):
(testPrivateGetterOnStruct.B):
(testPrivateGetterOnStruct.D.prototype.get x):
(testPrivateGetterOnStruct.D):
(testPrivateGetterOnStruct):
(testGCSurvival.B):
(testGCSurvival.D.prototype.m):
(testGCSurvival.D):
(testGCSurvival):
* Source/JavaScriptCore/runtime/JSObjectInlines.h:
(JSC::JSObject::getPrivateField):
(JSC::JSObject::setPrivateField):
(JSC::JSObject::definePrivateField):
(JSC::JSObject::setPrivateBrand):
Identifier: 305413.881@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.893@webkitglib/2.52
Commit: f0b744f0c4d106c6a6388f11c12bd92128fb8a2b
https://github.com/WebKit/WebKit/commit/f0b744f0c4d106c6a6388f11c12bd92128fb8a2b
Author: Zak Ridouh <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
A
LayoutTests/webanimations/threaded-animations/scroll-driven-animation-registry-update-crash-expected.txt
A
LayoutTests/webanimations/threaded-animations/scroll-driven-animation-registry-update-crash.html
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.cpp
M Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.h
Log Message:
-----------
Cherry-pick 3bff1cc45724. https://bugs.webkit.org/show_bug.cgi?id=314585
Fix Cross-thread use-after-free in
RemoteScrollingTree::m_progressBasedTimelineRegistry
<https://bugs.webkit.org/show_bug.cgi?id=314585>
<rdar://176483524>
Reviewed by Antoine Quint.
m_progressBasedTimelineRegistry was freed on the main thread by
updateTimelinesRegistration() while the ScrollingThread read it via
serviceScrollAnimations -> updateProgressBasedTimelinesForNode,
producing an ASan heap-use-after-free. The reader held m_treeLock; the
writer held only m_animationLock, so the two paths were not serialized.
Add a dedicated m_progressBasedTimelineRegistryLock that guards the
registry pointer and is acquired by every reader and writer. A separate
lock avoids self-deadlock when scrollingTreeNodeDidScroll() reaches
updateProgressBasedTimelinesForNode from the commit path with
m_treeLock already held.
Test:
webanimations/threaded-animations/scroll-driven-animation-registry-update-crash.html
*
LayoutTests/webanimations/threaded-animations/scroll-driven-animation-registry-update-crash-expected.txt:
Added.
*
LayoutTests/webanimations/threaded-animations/scroll-driven-animation-registry-update-crash.html:
Added.
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.cpp:
(WebKit::RemoteScrollingTree::updateTimelinesRegistration):
(WebKit::RemoteScrollingTree::timeline const):
(WebKit::RemoteScrollingTree::updateProgressBasedTimelinesForNode):
(WebKit::RemoteScrollingTree::timelinesForScrollingNodeIDForTesting const):
* Source/WebKit/UIProcess/RemoteLayerTree/RemoteScrollingTree.h:
Identifier: 305413.960@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.894@webkitglib/2.52
Commit: 1c19f7b2abfd741b09e44fe8bdebb204118ac2be
https://github.com/WebKit/WebKit/commit/1c19f7b2abfd741b09e44fe8bdebb204118ac2be
Author: Anand Srinivasan <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
A JSTests/wasm/stress/streaming-compile-try-table-agreement.js
M Source/JavaScriptCore/wasm/WasmEntryPlan.cpp
M Source/JavaScriptCore/wasm/WasmEntryPlan.h
M Source/JavaScriptCore/wasm/WasmIPIntPlan.cpp
M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp
M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.h
Log Message:
-----------
Cherry-pick 55fe8eb4c2a9. https://bugs.webkit.org/show_bug.cgi?id=315365
Streaming compiler does not reject mixed legacy and spec-correct EH
https://bugs.webkit.org/show_bug.cgi?id=315365
rdar://177030377
Reviewed by Yijia Huang.
Legacy EH instructions are not defined in the wasm spec but are still
supported for backwards compatibility. Functions must either use legacy
or standards compliant EH instructions but not both, and the streaming
compiler needs to be updated to enforce this.
Test: JSTests/wasm/stress/streaming-compile-try-table-agreement.js
* JSTests/wasm/stress/streaming-compile-try-table-agreement.js: Added.
(compileNonStreaming):
(async compileStreaming):
(async main):
* Source/JavaScriptCore/wasm/WasmEntryPlan.cpp:
(JSC::Wasm::EntryPlan::compileFunctions):
(JSC::Wasm::EntryPlan::failIfMixedExceptionHandlingProposals):
* Source/JavaScriptCore/wasm/WasmEntryPlan.h:
* Source/JavaScriptCore/wasm/WasmIPIntPlan.cpp:
(JSC::Wasm::IPIntPlan::completeInStreaming):
* Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp:
(JSC::IPInt::rethrowSlotForDepth):
(JSC::IPInt::WASM_IPINT_EXTERN_CPP_DECL):
* Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.h:
Identifier: 305413.963@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.895@webkitglib/2.52
Commit: bc2c08c0be62fe91811ca2e285df031cf04eaec4
https://github.com/WebKit/WebKit/commit/bc2c08c0be62fe91811ca2e285df031cf04eaec4
Author: Chris Dumez <[email protected]>
Date: 2026-07-02 (Thu, 02 Jul 2026)
Changed paths:
M Source/WebKit/UIProcess/Extensions/API/WebExtensionContextAPIStorage.cpp
Log Message:
-----------
Cherry-pick de9fb008197a. https://bugs.webkit.org/show_bug.cgi?id=315538
[WebKit Process Model] Use-after-free in WebExtensionContext::storageSet from
HashMap mutation during keys() iteration
https://bugs.webkit.org/show_bug.cgi?id=315538
rdar://177375129
Reviewed by Timothy Hatcher.
When WebExtensionStorageSQLiteStore::setKeyedData hits an INSERT error
mid-batch (e.g. SQLITE_FULL), it returns a keysSuccessfullySet vector
that is non-empty but smaller than the input map. The completion lambda
in storageSet then iterated `data.keys()` while calling `data.remove()`
inside the loop. `keys()` returns a live iterator range backed by raw
pointers into the HashTable buffer, and remove() can shrink/rehash and
free that buffer, leaving the iterator dangling — a heap UAF in the UI
Process driven by IPC from the WebContent process.
Replace the iterate-and-mutate loop with HashMap::removeIf, which walks
the table safely.
* Source/WebKit/UIProcess/Extensions/API/WebExtensionContextAPIStorage.cpp:
(WebKit::WebExtensionContext::storageSet):
Identifier: 305413.961@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.896@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/a3630df607da...bc2c08c0be62
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
