Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 66cde51161379e158cf63df19a873277eec02c3d
https://github.com/WebKit/WebKit/commit/66cde51161379e158cf63df19a873277eec02c3d
Author: Shu-yu Guo <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A
JSTests/stress/multi-put-by-offset-reallocating-storage-needs-write-barrier.js
M Source/JavaScriptCore/dfg/DFGStoreBarrierInsertionPhase.cpp
Log Message:
-----------
Cherry-pick 2b4933eb1658. https://bugs.webkit.org/show_bug.cgi?id=314747
[JSC] Insert barrier for MultiPutByOffset when it can reallocate storage
https://bugs.webkit.org/show_bug.cgi?id=314747
rdar://176792407
Reviewed by Keith Miller.
The DFG barrier insertion phase works by tracking an "epoch" serial number,
which is bumped every time it encounters a node that can GC. The assumption is
that each DFG node either does a store, which would need to be considered for
barrier insertion, or performs a GC.
MultiPutByOffset is a "fat" node that can GC and perform a store after that GC,
in sequence. The current analysis therefore incorrectly elides the barrier for
it. This PR fixes by special casing.
Test:
JSTests/stress/multi-put-by-offset-reallocating-storage-needs-write-barrier.js
*
JSTests/stress/multi-put-by-offset-reallocating-storage-needs-write-barrier.js:
Added.
(foo):
* Source/JavaScriptCore/dfg/DFGStoreBarrierInsertionPhase.cpp:
Identifier: 305413.909@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.897@webkitglib/2.52
Commit: aa1dbc722be32b64e7ab29de7a0dd8a105cea38e
https://github.com/WebKit/WebKit/commit/aa1dbc722be32b64e7ab29de7a0dd8a105cea38e
Author: Ryosuke Niwa <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A
LayoutTests/fast/dom/close-watcher/remove-watcher-from-non-last-group-crash-expected.txt
A
LayoutTests/fast/dom/close-watcher/remove-watcher-from-non-last-group-crash.html
M Source/WebCore/html/closewatcher/CloseWatcherManager.cpp
Log Message:
-----------
Cherry-pick cf6a686e2e58. https://bugs.webkit.org/show_bug.cgi?id=315591
Crash in CloseWatcherManager::remove
https://bugs.webkit.org/show_bug.cgi?id=315591
rdar://177972424
Reviewed by Darin Adler and Geoffrey Garen.
Don't mutate m_groups while iterating over it.
Test: fast/dom/close-watcher/remove-watcher-from-non-last-group-crash.html
*
LayoutTests/fast/dom/close-watcher/remove-watcher-from-non-last-group-crash-expected.txt:
Added.
*
LayoutTests/fast/dom/close-watcher/remove-watcher-from-non-last-group-crash.html:
Added.
* Source/WebCore/html/closewatcher/CloseWatcherManager.cpp:
(WebCore::CloseWatcherManager::remove):
Identifier: 305413.973@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.898@webkitglib/2.52
Commit: 5e4cc2f51cff725b7e252d7bb449a8441fa5c79b
https://github.com/WebKit/WebKit/commit/5e4cc2f51cff725b7e252d7bb449a8441fa5c79b
Author: Ryosuke Niwa <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A LayoutTests/fast/dom/StyleSheet/gc-import-rule-stylesheet-expected.txt
A LayoutTests/fast/dom/StyleSheet/gc-import-rule-stylesheet.html
M Source/WebCore/bindings/js/JSStyleSheetCustom.h
M Source/WebCore/css/CSSImportRule.cpp
M Source/WebCore/css/CSSImportRule.h
M Source/WebCore/css/CSSStyleSheet.cpp
M Source/WebCore/css/CSSStyleSheet.h
M Source/WebCore/css/StyleSheet.h
M Source/WebCore/xml/XSLStyleSheet.h
M Source/WebCore/xml/XSLStyleSheetLibxslt.cpp
Log Message:
-----------
Cherry-pick f41030176464. https://bugs.webkit.org/show_bug.cgi?id=312540
Data race in JSStyleSheet::visitAdditionalChildren during GC leading to
use-after-free
https://bugs.webkit.org/show_bug.cgi?id=312540
rdar://174207086
Reviewed by Antti Koivisto.
JSStyleSheet::visitAdditionalChildren is called by the JSC garbage collector on
a GC thread.
It calls addWebCoreOpaqueRoot(visitor, wrapped()) with root(StyleSheet*), which
reads
styleSheet->ownerNode() and styleSheet->ownerRule(). Both are WeakPtr member
variables on
CSSStyleSheet or XSLStyleSheet with .get() returning a raw pointer with no ref
count increment,
and the backing WeakPtrImpl can be freed by the main thread between the read
and the subsequent
dereference, causing a heap use-after-free.
The same root(StyleSheet*) function is the convergence point for JSCSSRule's
visitAdditionalChildren and JSCSSStyleDeclaration's visitAdditionalChildren, so
all three GC
visitor paths are affected.
To address this bug, this PR adds a pure virtual opaqueRootForGCThread() to so
root(StyleSheet*)
becomes a single virtual dispatch, eliminating the unsafe inline chain
traversal. This function
then uses a newly added lock (m_opaqueRootLockForGC in CSSStyleSheet and
XSLStyleSheet) to
guard against m_ownerNode being modified while the main thread is mutating it.
In addition, we had a GC correctness bug that @import child stylesheets (which
have m_ownerRule
but no m_ownerNode) would not keep its parent stylesheet's JS wrapper alive
even though it's
accessible via parentStyleSheet property.
To implement these changes and to avoid thread safety issues, this PR changes
the type of
m_ownerNode and m_ownerRule in CSSStyleSheet and XSLStyleSheet from WeakPtr to
CheckedPtr since
WeakPtr loads the pointee address via WeakPtrImpl, which may be concurrently
free'ed in the main
thread while we're accessing it in a GC thread. Note that all owner element
destructors
(HTMLStyleElement, HTMLLinkElement, SVGStyleElement, ProcessingInstruction)
call clearOwnerNode()
before the Node base-class destructor, so the CheckedPtr count reaches zero in
time. Similarly,
learOwnerRule() is called from the CSSImportRule and StyleRuleImport
destructors before
CSSImportRule is freed so CheckedPtr's assertion should not fire.
No new tests for the data race issue itself since there is no reliable way of
testing it.
Test: fast/dom/StyleSheet/gc-import-rule-stylesheet.html
* LayoutTests/fast/dom/StyleSheet/gc-import-rule-stylesheet-expected.txt: Added.
* LayoutTests/fast/dom/StyleSheet/gc-import-rule-stylesheet.html: Added.
* Source/WebCore/bindings/js/JSStyleSheetCustom.h:
(WebCore::root):
* Source/WebCore/css/CSSImportRule.cpp:
* Source/WebCore/css/CSSImportRule.h:
* Source/WebCore/css/CSSStyleSheet.cpp:
(WebCore::CSSStyleSheet::clearOwnerNode):
(WebCore::CSSStyleSheet::opaqueRootForGCThread):
(WebCore::CSSStyleSheet::clearOwnerRule):
* Source/WebCore/css/CSSStyleSheet.h:
* Source/WebCore/css/StyleSheet.h:
* Source/WebCore/xml/XSLStyleSheet.h:
* Source/WebCore/xml/XSLStyleSheetLibxslt.cpp:
(WebCore::XSLStyleSheet::XSLStyleSheet):
(WebCore::XSLStyleSheet::clearOwnerNode):
(WebCore::XSLStyleSheet::opaqueRootForGCThread):
Identifier: 305413.691@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.899@webkitglib/2.52
Commit: 70ede0ef05420aa218b8e0f0e8adfd86df5e68f6
https://github.com/WebKit/WebKit/commit/70ede0ef05420aa218b8e0f0e8adfd86df5e68f6
Author: Antoine Quint <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A
LayoutTests/webanimations/accelerated-animation-with-view-progress-timeline-range-but-no-timeline-expected.txt
A
LayoutTests/webanimations/accelerated-animation-with-view-progress-timeline-range-but-no-timeline.html
M Source/WebCore/animation/KeyframeEffect.cpp
Log Message:
-----------
Cherry-pick 347b3963d6ca. https://bugs.webkit.org/show_bug.cgi?id=314086
[web-animations] accelerated animation with view progress timeline range but no
timeline yields a crash
https://bugs.webkit.org/show_bug.cgi?id=314086
rdar://175530372
Reviewed by Ryosuke Niwa.
Ensure we only attempt to resolve animated styles for keyframes with a computed
offset in `KeyframeEffect::computeExtentOfTransformAnimation()`.
Test:
webanimations/accelerated-animation-with-view-progress-timeline-range-but-no-timeline.html
*
LayoutTests/webanimations/accelerated-animation-with-view-progress-timeline-range-but-no-timeline-expected.txt:
Added.
*
LayoutTests/webanimations/accelerated-animation-with-view-progress-timeline-range-but-no-timeline.html:
Added.
* Source/WebCore/animation/KeyframeEffect.cpp:
(WebCore::KeyframeEffect::computeExtentOfTransformAnimation const):
Identifier: 305413.835@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.900@webkitglib/2.52
Commit: 3c7ca7019d0334140a800622c140cc620cbf7937
https://github.com/WebKit/WebKit/commit/3c7ca7019d0334140a800622c140cc620cbf7937
Author: Marcus Plutowski <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
M Source/bmalloc/libpas/src/libpas/pas_race_test_hooks.h
M Source/bmalloc/libpas/src/libpas/pas_segregated_heap.c
M Source/bmalloc/libpas/src/libpas/pas_segregated_heap_inlines.h
M Source/bmalloc/libpas/src/test/RaceTests.cpp
Log Message:
-----------
Cherry-pick 58ebed1e9cec. https://bugs.webkit.org/show_bug.cgi?id=314829
[libpas] Fix race in pas_segregated_heap_medium_size_directory_for_index
https://bugs.webkit.org/show_bug.cgi?id=314829
rdar://175683224
Reviewed by Dan Hecht and Yijia Huang.
The medium-size directory is protected by both the heap-lock and a
seqlock (i.e. pas_mutation_count on rare_data->mutation_count).
The seqlock allows for readers to access the rare_data without
acquiring a lock; if the mutation-count shows that the object is being
mutated, then the reader is supposed to fall-back to acquiring the
heap-lock. However, as an optimization, if the heap-lock is already
held, the reader skips the seqlock step.
Previously, pas_segregated_heap_size_directory_for_index_slow would
always call pas_segregated_heap_medium_size_directory_for_index with
pas_lock_is_held. This meant that in certain cases, slow-path calls
will hit a race that results in a malloc call being given a slot within
segregated-heap slot that is actually too small for the requested size.
Operationally, what would happen is more or less
1. ThreadA tries allocating an object X and searches for a
matching medium-size-directory, but fails to find one.
2. This means it needs to create a new medium-size-directory.
This requires inserting a new entry into the medium-tuple array.
ThreadA determines that the new tuple should live at index M.
3. The medium-tuple array is sorted and packed, so inserting into the
middle requires `memmove`'ing all tuples down one slot --
so ThreadA does so.
At this point, slot[M] still points to the old entry,
and still has the old begin/end.
3. ThreadA then begins overwriting the slot[M], first
overwriting the directory-pointer.
At this point, slot[M] still has the old begin/end,
but points to the new directory.
4. ThreadB tries allocating an object Y. It should take the seqlock
here, but incorrectly assumes that it holds the heap-lock and thus
doesn't need to.
5. ThreadB searches for a matching medium-size-directory, and finds
slot[M] has a begin/end pair that matches its expectations.
6. ThreadB then reads slot[M]'s directory pointer, thus
getting a directory with a mismatched size.
7. ThreadB then asks that directory for an allocation-slot,
and gets one back: however, the size of this slot is
necessarily too small (because of the sorted-insertion
requirement in #3 above).
Therefore, the caller thinks that it got e.g. an 8192B
slot but in fact only got a 7162B slot. A write to the
latter bytes of the slot will corrupt the memory of the
subsequent allocation.
N.b. step #3 is also a race on its own, but it's harder to capture
since we can't hook in the middle of the memmove.
Best as I can tell, at some point this hardcoded heap-lock hold mode
was actually correct, since the primary path to get here does acquire
the lock. However, there's another path (perhaps added later?
unfortunately it's all lumped into the commit that added libpas to the
repo) that doesn't do so. So the correct fix is to pipe the heap-lock
hold status up far enough that we either get to a function that takes
the hold-mode as a parameter, or one which asserts that the heap-lock
is held.
* Source/bmalloc/libpas/src/libpas/test/RaceTests.cpp: added
new test to exhibit the race described above.
Identifier: 305413.966@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.901@webkitglib/2.52
Commit: 3940a0303e2877e0580a496448e56e0ce3d34054
https://github.com/WebKit/WebKit/commit/3940a0303e2877e0580a496448e56e0ce3d34054
Author: Said Abou-Hallawa <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
M
Source/WebCore/platform/graphics/filters/software/FEGaussianBlurSoftwareApplier.cpp
Log Message:
-----------
Cherry-pick 96b0a368415e. https://bugs.webkit.org/show_bug.cgi?id=314345
Uninitialized result of FEGaussianBlur if the input isAlphaImage
https://bugs.webkit.org/show_bug.cgi?id=314345
rdar://175674593
Reviewed by Simon Fraser.
`FEGaussianBlurSoftwareApplier::apply()` creates uninitialized `tempBuffer`
through `createScratchPixelBuffer()`.
-- If the stdDeviation of feGaussianBlur is asymmetric, e.g. "5 0", then
applying
this filter falls back to `boxBlurUnaccelerated()`.
-- If the input of feGaussianBlur isAlphaImage, e.g.
feColorMatrix(luminanceToAlpha),
then `boxBlur()` short-circuits to `boxBlurAlphaOnly()`, which writes only
the alpha channel of each pixel.
-- If one of the stdDeviation is zero, e.g. "5 0", `boxBlurUnaccelerated()` will
copy the `tempBuffer` to the `destinationPixelBuffer` with three
uninitialized
channels before it returns.
If isAlphaImage is true Make sure `tempBuffer` is zero-filled.
*
Source/WebCore/platform/graphics/filters/software/FEGaussianBlurSoftwareApplier.cpp:
(WebCore::FEGaussianBlurSoftwareApplier::boxBlurGeneric):
Identifier: 305413.858@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.902@webkitglib/2.52
Commit: b7889ad3cc4f12efe5329f6a3266c07c68185b20
https://github.com/WebKit/WebKit/commit/b7889ad3cc4f12efe5329f6a3266c07c68185b20
Author: Anand Srinivasan <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A JSTests/stress/yarr-negative-offset.js
M Source/JavaScriptCore/yarr/YarrJIT.cpp
Log Message:
-----------
Cherry-pick 30c8460241f3. https://bugs.webkit.org/show_bug.cgi?id=312415
YarrJIT negativeOffsetIndexedAddress discards adjusted base register
https://bugs.webkit.org/show_bug.cgi?id=312415
rdar://174714198
Reviewed by Yijia Huang.
In YarrJIT negativeOffsetIndexedAddress computes a negative offset from
a base address but the function mistakenly uses the original value
instead of the adjusted value. This patch fixes it to use the adjusted
value.
Test: JSTests/stress/yarr-negative-offset.js
* JSTests/stress/yarr-negative-offset.js: Added.
(catch):
* Source/JavaScriptCore/yarr/YarrJIT.cpp:
Identifier: 305413.685@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.903@webkitglib/2.52
Commit: a606bccf2adbf0d4bdc3289a1b47bd884111b62f
https://github.com/WebKit/WebKit/commit/a606bccf2adbf0d4bdc3289a1b47bd884111b62f
Author: Roberto Rodriguez <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A
LayoutTests/fast/canvas/webgl/context-restore-concurrent-gc-no-crash-expected.txt
A LayoutTests/fast/canvas/webgl/context-restore-concurrent-gc-no-crash.html
M Source/WebCore/html/canvas/WebGL2RenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContext.h
M Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp
M Source/WebCore/html/canvas/WebGLRenderingContextBase.h
Log Message:
-----------
Cherry-pick 6d64b1760e9a. https://bugs.webkit.org/show_bug.cgi?id=315161
[WebGL] Missing objectGraphLock on WebGL context restore races with GC
https://bugs.webkit.org/show_bug.cgi?id=315161
rdar://177359720
Reviewed by Kimmo Kinnunen.
All mutators of the WebGL bound-object graph hold objectGraphLock to
synchronize with
addMembersToOpaqueRoots on the GC helper thread, except for
initializeContextState and
initializeDefaultObjects on the WEBGL_lose_context restore path. That path
reassigns
binding points for the default WebGLTransformFeedback and
WebGLVertexArrayObject, freeing
them while the GC marker may still be traversing them.
Fix by holding objectGraphLock in initializeNewContext around both calls and add
WTF_REQUIRES_LOCK annotations to catch this at compile time.
Test: fast/canvas/webgl/context-restore-concurrent-gc-no-crash.html
*
LayoutTests/fast/canvas/webgl/context-restore-concurrent-gc-no-crash-expected.txt:
Added.
* LayoutTests/fast/canvas/webgl/context-restore-concurrent-gc-no-crash.html:
Added.
* Source/WebCore/html/canvas/WebGL2RenderingContext.h:
* Source/WebCore/html/canvas/WebGLRenderingContext.h:
* Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:
(WebCore::WebGLRenderingContextBase::initializeNewContext):
* Source/WebCore/html/canvas/WebGLRenderingContextBase.h:
Identifier: 305413.940@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.904@webkitglib/2.52
Commit: ef88aa955291fa2a12defd63586a4d4ba2f5a5e0
https://github.com/WebKit/WebKit/commit/ef88aa955291fa2a12defd63586a4d4ba2f5a5e0
Author: Kimmo Kinnunen <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
M Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp
Log Message:
-----------
Cherry-pick dd484347691b. https://bugs.webkit.org/show_bug.cgi?id=312566
WebGL: GraphicsContextGLANGLE PACK_* state is modifiable through pixelStorei
https://bugs.webkit.org/show_bug.cgi?id=312566
rdar://174740214
Reviewed by Dan Glastonbury.
Filter out pixelStorei parameters.
* Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp:
(WebCore::GraphicsContextGLANGLE::pixelStorei):
Identifier: 305413.710@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.905@webkitglib/2.52
Commit: 902c41b6c73302a9b92aad90df4ace31a7f2c2ff
https://github.com/WebKit/WebKit/commit/902c41b6c73302a9b92aad90df4ace31a7f2c2ff
Author: Rupin Mittal <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
Log Message:
-----------
Cherry-pick 9fd9439df22f. https://bugs.webkit.org/show_bug.cgi?id=313866
WebResourceLoader::WillSendRequest reply may lead to cross-origin cookie access
https://bugs.webkit.org/show_bug.cgi?id=313866
rdar://174663032
Reviewed by Per Arne Vollan.
Consider this sequence of events:
1. A compromised web process schedules a load with its own origin used for
firstPartyForCookies.
2. NetworkConnectionToWebProcess::scheduleResourceLoad() is called and the
message check passes.
3. The request goes through and the server responds with 302 (redirect).
4. NetworkResourceLoader::continueWillSendRedirectedRequest() calls
WebResourceLoader::WillSendRequest() which gives the web process the chance
to alter the request that will be sent to perform the redirect.
5. The compromised web process alters the request so that firstPartyForCookies
is now a different origin.
6. NetworkResourceLoader::continueWillSendRequest() receives this altered
request and passes it off to CFNetwork.
7. The result of this request is that the compromised web process receives
the cookies of this different origin.
There are multiple callsites of continueWillSendRequest(), but only one place
which allows the web process to alter the request before it's given to
continueWillSendRequest(). So we fix this by adding a message check right
before that callsite that will double check that the origin contained in this
potentially modified request from the web process is in this web process's
allowed list. If not, the web process will be killed so that it doesn't recieve
the cross-origin cookies.
We also only do this message check if the web process actually changes the
origin. This is because there are cases where the origin is not yet in the
allowlist but not because the web process modified it (like in:
imported/w3c/web-platform-tests/speculation-rules/prefetch/redirect-url.https.html?origin=cross-site-redirect
where there is a cross-site redirect as part of a prefetch, so the cross-site
origin is supplied by the server but hasn't made it into the allow list since
the navigation to it is not complete).
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::continueWillSendRedirectedRequest):
Identifier: 305413.834@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.906@webkitglib/2.52
Commit: c0887a6ed84d0d5160dceb75278f9eb1833f5163
https://github.com/WebKit/WebKit/commit/c0887a6ed84d0d5160dceb75278f9eb1833f5163
Author: Brady Eidson <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
M Source/WebKit/UIProcess/WebBackForwardList.cpp
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Tools/TestWebKitAPI/Tests/WebKit/WKBackForwardListTests.mm
Log Message:
-----------
Cherry-pick 249edf86a9f5. https://bugs.webkit.org/show_bug.cgi?id=313866
Need a process-specific `WebBackForwardListItem::allItems()` instead of the
process-global map for better message checking
rdar://174702519
Reviewed by Ben Nham.
When considering whether a given web process should have access to a given
back/forward entry,
the global map is the wrong tool.
Check on a per-process basis instead.
Test: Tools/TestWebKitAPI/Tests/WebKit/WKBackForwardListTests.mm
* Source/WebKit/UIProcess/WebBackForwardList.cpp:
(WebKit::messageCheckItemURLs):
(WebKit::WebBackForwardList::backForwardAddItemShared):
(WebKit::WebBackForwardList::backForwardSetChildItem):
(WebKit::WebBackForwardList::backForwardUpdateItem):
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::checkURLReceivedFromWebProcess):
* Tools/TestWebKitAPI/Tests/WebKit/WKBackForwardListTests.mm:
(<script>):
(ForgedFileURLItemIsRejected)):
Identifier: 305413.831@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.907@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/bc2c08c0be62...c0887a6ed84d
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
