Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 8406a3c70f4ce9952d2ac989b8a559ae67454719
https://github.com/WebKit/WebKit/commit/8406a3c70f4ce9952d2ac989b8a559ae67454719
Author: Anne van Kesteren <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
M Source/WebCore/Modules/webxr/WebXRSystem.cpp
M Source/WebCore/Modules/webxr/WebXRSystem.h
M Source/WebCore/Modules/webxr/XRSessionInit.h
M Source/WebCore/Modules/webxr/XRSessionInit.idl
M Source/WebCore/bindings/IDLTypes.h
M Source/WebCore/testing/WebXRTest.cpp
M Source/WebCore/testing/WebXRTest.h
M Source/WebCore/testing/WebXRTest.idl
Log Message:
-----------
Cherry-pick 65ba1780134a. https://bugs.webkit.org/show_bug.cgi?id=312348
Use-after-free in XRSessionInit dictionary conversion via sequence<any>
https://bugs.webkit.org/show_bug.cgi?id=312348
rdar://174448452
Reviewed by Ryosuke Niwa.
sequence<any> and FrozenArray<any> are fundamentally unsafe as
currently implemented. Fortunately the only place where we use
sequence<any> can use sequence<DOMString>.
So adopt sequence<DOMString> there and add static asserts to prevent
future adoption of the unsafe constructs.
Identifier: 305413.680@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.810@webkitglib/2.52
Commit: 55aeb61fc70165ba52f4f3165c90142956519344
https://github.com/WebKit/WebKit/commit/55aeb61fc70165ba52f4f3165c90142956519344
Author: Chris Dumez <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
M Source/WebCore/fileapi/AsyncFileStream.cpp
M Source/WebCore/fileapi/AsyncFileStream.h
M Source/WebCore/platform/FileStreamClient.h
M Source/WebCore/platform/network/BlobResourceHandle.cpp
M Source/WebCore/platform/network/BlobResourceHandleBase.cpp
M Source/WebCore/platform/network/BlobResourceHandleBase.h
M Source/WebKit/NetworkProcess/NetworkDataTaskBlob.cpp
Log Message:
-----------
Cherry-pick 70917758773a. https://bugs.webkit.org/show_bug.cgi?id=312449
Cross-Thread UAF Write in AsyncFileStream::read via NetworkDataTaskBlob
https://bugs.webkit.org/show_bug.cgi?id=312449
rdar://174655475
Reviewed by Ryosuke Niwa.
BlobResourceHandleBase was passing a mutable span to its m_buffer Vector
to AsyncFileStream for it to write into asynchronously on a background
thread. However, nothing guaranteed that the BlobResourceHandleBase
(and thus its m_buffer) stayed alive until AsyncFileStream was done
writing.
Address the issue by using a `Box<Vector<uint8_t>>` instead of a simple
Vector so that the buffer is now ThreadSafeRefCounted. Then update the
AsyncFileStream API to take in a `Box<Vector<uint8_t>>` instead of a
span.
For further hardening, I removed the non-const buffer getter on
BlobResourceHandleBase. This was too dangerous because any operation on
this buffer on the main thread could cause the background thread to
crash if it is currently writing to it. The non-const buffer getter was
only used to resize the buffer once we know the size of the data we
need to read. I thus added a more specific `resizeBuffer()` API to
BlobResourceHandleBase which has a RELEASE_ASSERT() to guarantee that
the background thread is NOT currently writing into the buffer. This was
not an issue with the current code but the RELEASE_ASSERT() makes sure
we cannot introduce such a security bug in the future.
* Source/WebCore/fileapi/AsyncFileStream.cpp:
(WebCore::AsyncFileStream::read):
* Source/WebCore/fileapi/AsyncFileStream.h:
* Source/WebCore/platform/FileStreamClient.h:
(WebCore::FileStreamClient::didGetSize):
(WebCore::FileStreamClient::didRead): Deleted.
* Source/WebCore/platform/network/BlobResourceHandle.cpp:
(WebCore::BlobResourceHandle::didReceiveResponse):
* Source/WebCore/platform/network/BlobResourceHandleBase.cpp:
(WebCore::BlobResourceHandleBase::BlobResourceHandleBase):
(WebCore::BlobResourceHandleBase::resizeBuffer):
(WebCore::BlobResourceHandleBase::readFileAsync):
(WebCore::BlobResourceHandleBase::didRead):
* Source/WebCore/platform/network/BlobResourceHandleBase.h:
(WebCore::BlobResourceHandleBase::buffer): Deleted.
(WebCore::BlobResourceHandleBase::buffer const): Deleted.
* Source/WebKit/NetworkProcess/NetworkDataTaskBlob.cpp:
(WebKit::NetworkDataTaskBlob::didReceiveResponse):
Identifier: 305413.682@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.811@webkitglib/2.52
Commit: e2ac8db736b5f04843cd49e8df370af45478df72
https://github.com/WebKit/WebKit/commit/e2ac8db736b5f04843cd49e8df370af45478df72
Author: Charlie Wolfe <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
M Source/WebCore/loader/NavigationAction.cpp
M Source/WebCore/loader/NavigationAction.h
M Source/WebKit/Shared/NavigationActionData.h
M Source/WebKit/Shared/NavigationActionData.serialization.in
M Source/WebKit/UIProcess/API/APINavigation.h
M Source/WebKit/UIProcess/WebProcessPool.cpp
M Source/WebKit/UIProcess/win/AutomationSessionClientWin.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp
Log Message:
-----------
Cherry-pick 8bb359efde80. https://bugs.webkit.org/show_bug.cgi?id=312445
Remove treatAsSameOriginNavigation from NavigationActionData IPC
https://bugs.webkit.org/show_bug.cgi?id=312445
rdar://174702490
Reviewed by Rupin Mittal.
A compromised WebContent process could forge treatAsSameOriginNavigation in
DecidePolicyForNavigationAction to skip the cross-site process swap in
processForNavigationInternal.
Remove the field from NavigationActionData, NavigationAction, and
API::Navigation, and compute it
directly in processForNavigationInternal from the target URL protocol and the
UIProcess-owned
sourceURL.
* Source/WebCore/loader/NavigationAction.cpp:
(WebCore::shouldTreatAsSameOriginNavigation): Deleted.
* Source/WebCore/loader/NavigationAction.h:
(WebCore::NavigationAction::treatAsSameOriginNavigation const): Deleted.
* Source/WebKit/Shared/NavigationActionData.h:
* Source/WebKit/Shared/NavigationActionData.serialization.in:
* Source/WebKit/UIProcess/API/APINavigation.h:
(API::Navigation::treatAsSameOriginNavigation const): Deleted.
* Source/WebKit/UIProcess/WebProcessPool.cpp:
(WebKit::WebProcessPool::processForNavigationInternal):
* Source/WebKit/UIProcess/win/AutomationSessionClientWin.cpp:
(WebKit::AutomationSessionClient::requestNewPageWithOptions):
* Source/WebKit/WebProcess/WebCoreSupport/WebChromeClient.cpp:
(WebKit::WebChromeClient::createWindow):
* Source/WebKit/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::navigationActionData const):
* Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp:
(WebKit::WebLocalFrameLoaderClient::didSameDocumentNavigationForFrameViaJS):
(WebKit::WebLocalFrameLoaderClient::dispatchDecidePolicyForNewWindowAction):
Identifier: 305413.684@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.812@webkitglib/2.52
Commit: 81803ac44937604803142c9eceb954739807bd1c
https://github.com/WebKit/WebKit/commit/81803ac44937604803142c9eceb954739807bd1c
Author: Chris Dumez <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
A LayoutTests/workers/weblock-manager-query-crash-expected.txt
A LayoutTests/workers/weblock-manager-query-crash.html
M Source/WebCore/Modules/web-locks/WebLockManager.cpp
M Source/WebCore/Modules/web-locks/WebLockManager.h
Log Message:
-----------
Cherry-pick 0b964ced2532. https://bugs.webkit.org/show_bug.cgi?id=312456
UAF due to cross-thread destruction of worker DeferredPromise in
WebLockManager::query()
https://bugs.webkit.org/show_bug.cgi?id=312456
rdar://174652399
Reviewed by Ryosuke Niwa.
WebLockManager::MainThreadBridge::query() was taking in a CompletionHandler
but it may sometimes fail to call its completion handler. This happened
when the worker thread is exiting, causing
`ScriptExecutionContext::ensureOnContextThread()`
to fail. Not calling the completion handler is bad but what's worse is that
the completion handler would end up getting destroyed on the main thread.
The completion handler was capturing a promise from the worker thread,
which led to security bugs.
To address the issue:
1. Have WebLockManager::MainThreadBridge::query() take in a Function
instead of a CompletionHandler given that it cannot always call
its callback.
2. Have WebLockManager store the promise in a HashMap and only capture
a promise identifier in the MainThreadBridge::query() lambda instead
of the promise itself. This pattern was already used for other
promises in this class.
Test: workers/weblock-manager-query-crash.html
* LayoutTests/workers/weblock-manager-query-crash-expected.txt: Added.
* LayoutTests/workers/weblock-manager-query-crash.html: Added.
* Source/WebCore/Modules/web-locks/WebLockManager.cpp:
(WebCore::WebLockManager::MainThreadBridge::abortLockRequest):
(WebCore::WebLockManager::MainThreadBridge::query):
(WebCore::WebLockManager::query):
(WebCore::WebLockManager::clientIsGoingAway):
* Source/WebCore/Modules/web-locks/WebLockManager.h:
Identifier: 305413.688@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.813@webkitglib/2.52
Commit: 8880d43cf6be2b00703bbbff275fcb0e1797b4a3
https://github.com/WebKit/WebKit/commit/8880d43cf6be2b00703bbbff275fcb0e1797b4a3
Author: Mark Lam <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
A JSTests/stress/expression-info-multi-wide-encoding.js
M Source/JavaScriptCore/bytecode/ExpressionInfo.cpp
Log Message:
-----------
Cherry-pick e321c398762a. https://bugs.webkit.org/show_bug.cgi?id=312525
ExpressionInfo::Encoder computes the offset to Extension Islands incorrectly.
https://bugs.webkit.org/show_bug.cgi?id=312525
rdar://174626446
Reviewed by Yijia Huang.
When an Extension ExpressionInfo is emitted, it needs to encode a displacement
offset from
its location to the location of its extension island. For a MultiWide
ExpressionInfo,
parts of its island has already been emitted (from copying the MultiWide record
over). As
a result, the size of m_expressionInfoEncodedInfo is no longer the same as the
starting
offset of extension island. As a result, the offset encoded in the Extension
ExpressionInfo
will be incorrect.
The fix is simply to cache the location of the extension island before we start
copying the
MultiWide ExpressionInfo over. We will use this cached location to emit the
Extension
ExpressionInfo instead of using m_expressionInfoEncodedInfo.size() as we do for
other cases.
Also fixed some typos and errors in comments.
Also fixed the decoding of DuoWide field2 in ExpressionInfo::dumpEncodedInfo().
This is
only used for debugging code.
Test: JSTests/stress/expression-info-multi-wide-encoding.js
* JSTests/stress/expression-info-multi-wide-encoding.js: Added.
(catch):
* Source/JavaScriptCore/bytecode/ExpressionInfo.cpp:
(JSC::ExpressionInfo::Encoder::adjustInstPC):
(JSC::ExpressionInfo::dumpEncodedInfo):
Identifier: 305413.693@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.814@webkitglib/2.52
Commit: 752b942119d7547ed87e631d81a188111f467883
https://github.com/WebKit/WebKit/commit/752b942119d7547ed87e631d81a188111f467883
Author: Basuke Suzuki <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.h
M
Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.serialization.in
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
M Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp
Log Message:
-----------
Cherry-pick 1db91ab9400c. https://bugs.webkit.org/show_bug.cgi?id=312525
Remove shouldRestrictHTTPResponseAccess from NetworkResourceLoadParameters
rdar://174708348
Reviewed by Ryosuke Niwa.
The shouldRestrictHTTPResponseAccess field in NetworkResourceLoadParameters
was sent from WebContent process to NetworkProcess via IPC with no validation.
A compromised WebContent process could set it to false to bypass response
header sanitization (Set-Cookie stripping, cross-origin header filtering).
The field was originally introduced in 2018 as a runtime-configurable flag
(RestrictedHTTPResponseAccess preference) to allow WK1 to opt out of
sanitization. After WK1 was removed, the preference was hardcoded to true
(288687@main), but the IPC parameter was never cleaned up.
Since shouldPerformSecurityChecks() unconditionally returns true, this field
always carried the value true from a legitimate WebContent process. Remove
it entirely and make sanitization unconditional on the NetworkProcess side.
No new tests (hardening, no behavior change for legitimate WebContent process).
* Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.h:
* Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.serialization.in:
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::sanitizeResponseIfPossible):
* Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:
(WebKit::WebLoaderStrategy::scheduleLoadFromNetworkProcess):
(WebKit::WebLoaderStrategy::loadResourceSynchronously):
(WebKit::WebLoaderStrategy::startPingLoad):
(WebKit::WebLoaderStrategy::preconnectTo):
Identifier: 305413.689@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.815@webkitglib/2.52
Commit: 6fc19030a5d5b4f96d5d09273669405490dc440d
https://github.com/WebKit/WebKit/commit/6fc19030a5d5b4f96d5d09273669405490dc440d
Author: Kimmo Kinnunen <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
M Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGL.cpp
Log Message:
-----------
Cherry-pick 0c204da15932. https://bugs.webkit.org/show_bug.cgi?id=312564
WebGL: Uninitialized FastMalloc heap disclosure in
RemoteGraphicsContextGL::readPixelsInline
https://bugs.webkit.org/show_bug.cgi?id=312564
rdar://174640403
Reviewed by Dan Glastonbury.
Allocate the read pixels area with zero init.
* Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGL.cpp:
(WebKit::RemoteGraphicsContextGL::readPixelsInline):
Identifier: 305413.708@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.816@webkitglib/2.52
Commit: 9c1c3638d49ce5a6c0dfc36602a47f08ac79da30
https://github.com/WebKit/WebKit/commit/9c1c3638d49ce5a6c0dfc36602a47f08ac79da30
Author: Anthony Tarbinian <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
A
LayoutTests/webaudio/biquadfilternode-set-type-channel-count-race-expected.txt
A LayoutTests/webaudio/biquadfilternode-set-type-channel-count-race.html
M Source/WebCore/Modules/webaudio/BiquadFilterNode.cpp
Log Message:
-----------
Cherry-pick 41efaeddddf2. https://bugs.webkit.org/show_bug.cgi?id=312796
[WebCore] Take graphLock() in BiquadFilterNode::setType() to avoid race
with audio-thread kernel reallocation
rdar://174652790
https://bugs.webkit.org/show_bug.cgi?id=312796
Reviewed by Chris Dumez.
BiquadFilterNode::setType() runs on the main thread from JS bindings and calls
BiquadProcessor::setType(), which in turn calls AudioDSPKernelProcessor::reset()
to iterate m_kernels and virtual-call reset() on each kernel. This was done
without holding the context's graphLock().
Concurrently, every render quantum the audio thread runs
AudioBasicProcessorNode::checkNumberOfChannelsForInput() under graphLock() and,
when the input channel count has changed, calls uninitialize() / initialize()
on the processor, which clear()s and move-assigns m_kernels.
With the lock held only on one side, the main thread could load a kernel pointer
from a Vector slot that is being/already freed, leading to a use-after-free
virtual
dispatch into a destroyed BiquadDSPKernel and writes through stale Biquad
buffer spans, or a null deref if the slot was already zeroed.
Fix by taking context().graphLock() in BiquadFilterNode::setType(), matching the
existing convention in WaveShaperNode::setOversampleForBindings() and
AudioNode::setChannelCount().
Test: webaudio/biquadfilternode-set-type-channel-count-race.html
*
LayoutTests/webaudio/biquadfilternode-set-type-channel-count-race-expected.txt:
Added.
* LayoutTests/webaudio/biquadfilternode-set-type-channel-count-race.html: Added.
* Source/WebCore/Modules/webaudio/BiquadFilterNode.cpp:
(WebCore::BiquadFilterNode::setType):
Identifier: 305413.717@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.817@webkitglib/2.52
Commit: 15727c3012164902b132a6a21bb7f5e85f9c3c8c
https://github.com/WebKit/WebKit/commit/15727c3012164902b132a6a21bb7f5e85f9c3c8c
Author: Kai Tamkun <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
A JSTests/stress/slowputarraystorage-stale-structure-bit.js
M Source/JavaScriptCore/runtime/Structure.cpp
Log Message:
-----------
Cherry-pick dacb07e7c6bd. https://bugs.webkit.org/show_bug.cgi?id=312487
[JSC] Stale structure bit in SlowPutArrayStorage
https://bugs.webkit.org/show_bug.cgi?id=312487
rdar://172210517
Reviewed by Keith Miller.
Correctly sets HasNonConfigurableProperties and related bits during Structure
construction
if the IndexingType has an array storage shape.
Test: JSTests/stress/slowputarraystorage-stale-structure-bit.js
* JSTests/stress/slowputarraystorage-stale-structure-bit.js: Added.
(get k):
(get configurable):
(set t):
(catch):
* Source/JavaScriptCore/runtime/Structure.cpp:
(JSC::Structure::Structure):
Identifier: 305413.704@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.818@webkitglib/2.52
Commit: e5b8f463a4a9a6994ca10db9a58d36cc82bd4947
https://github.com/WebKit/WebKit/commit/e5b8f463a4a9a6994ca10db9a58d36cc82bd4947
Author: Kai Tamkun <[email protected]>
Date: 2026-07-01 (Wed, 01 Jul 2026)
Changed paths:
A JSTests/stress/resizable-array-constant-folding.js
M Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp
Log Message:
-----------
Cherry-pick 80760a59ebe9. https://bugs.webkit.org/show_bug.cgi?id=312781
[JSC] Use-after-free after Wasm memory grow via stale pointer folded by
DFGConstantFoldingPhase
https://bugs.webkit.org/show_bug.cgi?id=312781
rdar://174994263
Reviewed by Yijia Huang.
Exempts resizable/growable-shared views from GetIndexedPropertyStorage constant
folding.
Converting the vector to a constant storage pointer is invalid if the vector
can be
reallocated without notice.
resizable-array-constant-folding.js tests the effects of writing to a
WebAssembly
memory grown after constant folding.
* JSTests/stress/resizable-array-constant-folding.js: Added.
(trigger):
* Source/JavaScriptCore/dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
Identifier: 305413.726@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.819@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/5c9a25ef8b20...e5b8f463a4a9
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
