Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 5d87b66c79d041c09293189d38e0ed2d5f094779
https://github.com/WebKit/WebKit/commit/5d87b66c79d041c09293189d38e0ed2d5f094779
Author: Ronan Turner <[email protected]>
Date: 2025-11-12 (Wed, 12 Nov 2025)
Changed paths:
A
LayoutTests/fast/speechsynthesis/lockdown-mode/speech-synthesis-expected.txt
A LayoutTests/fast/speechsynthesis/lockdown-mode/speech-synthesis.html
M LayoutTests/platform/glib/TestExpectations
M LayoutTests/platform/mac-wk1/TestExpectations
M LayoutTests/platform/win/TestExpectations
M LayoutTests/platform/wpe/TestExpectations
M Source/WebCore/Modules/speech/DOMWindow+SpeechSynthesis.idl
M Source/WebCore/bindings/js/WebCoreBuiltinNames.h
Log Message:
-----------
Prevent speechSynthesis from being accessible in LDM.
https://bugs.webkit.org/show_bug.cgi?id=298382
rdar://159462101
Reviewed by Alex Christensen.
We were missing an EnabledBySetting=SpeechSynthesisAPIEnabled guard on the
DOMWindow+SpeechSynthesis.idl file. This results in window.speechSynthesis
still remaining accessible to sites, even when the setting is disabled. This
then results in process termination when the IPC message is attempted and the
privileged process marks the IPC message as invalid.
This adds the guard, and a new test to ensure this is sufficiently disabled
when in Lockdown Mode.
* LayoutTests/fast/speechsynthesis/lockdown-mode/speech-synthesis-expected.txt:
Added.
* LayoutTests/fast/speechsynthesis/lockdown-mode/speech-synthesis.html: Added.
* LayoutTests/platform/glib/TestExpectations:
* LayoutTests/platform/mac-wk1/TestExpectations:
* LayoutTests/platform/win/TestExpectations:
* LayoutTests/platform/wpe/TestExpectations:
* Source/WebCore/Modules/speech/DOMWindow+SpeechSynthesis.idl:
* Source/WebCore/bindings/js/WebCoreBuiltinNames.h:
Originally-landed-as: 297297.375@safari-7622-branch (7d5ef34062b7).
rdar://164277664
Canonical link: https://commits.webkit.org/302924@main
Commit: efe12c3441641637f8a4bdddcef7138b3b1df195
https://github.com/WebKit/WebKit/commit/efe12c3441641637f8a4bdddcef7138b3b1df195
Author: Aditya Keerthi <[email protected]>
Date: 2025-11-12 (Wed, 12 Nov 2025)
Changed paths:
M Source/WebKit/UIProcess/Cocoa/VideoPresentationManagerProxy.h
M Source/WebKit/UIProcess/Cocoa/VideoPresentationManagerProxy.mm
M Source/WebKit/UIProcess/PageClient.h
M Source/WebKit/UIProcess/ios/PageClientImplIOS.h
M Source/WebKit/UIProcess/ios/PageClientImplIOS.mm
M Source/WebKit/UIProcess/ios/WKContentView.h
M Source/WebKit/UIProcess/ios/WKContentView.mm
Log Message:
-----------
UAF may occur in `-[WKContentView .cxx_destruct]`
https://bugs.webkit.org/show_bug.cgi?id=298293
rdar://151523238
Reviewed by Abrar Rahman Protyasha.
UAFs have been observed when loading a weak reference from the (weak)
`NSHashTable` containing `WKVisibilityPropagationView`s.
The root cause of the issue is still unclear, since the references should have
been zeroed out. Mitigate the issue by using an `NSMutableSet` that strongly
references the `WKVisibilityPropagationView`s. This is safe to do since it does
not introduce a reference cycle. The only downside is additional manual
bookkeeping when the views are removed.
* Source/WebKit/UIProcess/Cocoa/VideoPresentationManagerProxy.h:
* Source/WebKit/UIProcess/Cocoa/VideoPresentationManagerProxy.mm:
(WebKit::VideoPresentationManagerProxy::setVisibilityPropagationViewForLayerHostView):
(WebKit::VideoPresentationManagerProxy::setupFullscreenWithID):
(WebKit::VideoPresentationManagerProxy::didCleanupFullscreen):
* Source/WebKit/UIProcess/PageClient.h:
(WebKit::PageClient::removeVisibilityPropagationView):
* Source/WebKit/UIProcess/ios/PageClientImplIOS.h:
* Source/WebKit/UIProcess/ios/PageClientImplIOS.mm:
(WebKit::PageClientImpl::removeVisibilityPropagationView):
* Source/WebKit/UIProcess/ios/WKContentView.h:
* Source/WebKit/UIProcess/ios/WKContentView.mm:
(-[WKContentView _createVisibilityPropagationView]):
(-[WKContentView _removeVisibilityPropagationView:]):
Originally-landed-as: 297297.376@safari-7622-branch (d159f371e83b).
rdar://164277707
Canonical link: https://commits.webkit.org/302925@main
Commit: 38178546e86677235938cda80ddc90711d567422
https://github.com/WebKit/WebKit/commit/38178546e86677235938cda80ddc90711d567422
Author: Sihui Liu <[email protected]>
Date: 2025-11-12 (Wed, 12 Nov 2025)
Changed paths:
M Source/WebCore/Modules/indexeddb/server/MemoryBackingStoreTransaction.cpp
M Source/WebCore/Modules/indexeddb/server/MemoryBackingStoreTransaction.h
Log Message:
-----------
Fix use-after-free in MemoryBackingStoreTransaction::abort
rdar://159649671
Reviewed by Per Arne Vollan and Rupin Mittal.
MemoryIndex can be destroyed after the last reference is removed in
MemoryBackingStoreTransaction::removeNewIndex(), but
MemoryBackingStoreTransaction::m_originalIndexNames might still keep the raw
pointer to the MemoryIndex, and when
transaction is aborted later, MemoryBackingStoreTransaction::abort would access
the pointer. To fix this, ensure
the MemoryIndex is removed from m_originalIndexNames in removeNewIndex(). Also,
to avoid this use-after-free issue,
make m_originalIndexNames store RefPtr instead of raw pointer.
* Source/WebCore/Modules/indexeddb/server/MemoryBackingStoreTransaction.cpp:
(WebCore::IDBServer::MemoryBackingStoreTransaction::removeNewIndex):
(WebCore::IDBServer::MemoryBackingStoreTransaction::abort):
* Source/WebCore/Modules/indexeddb/server/MemoryBackingStoreTransaction.h:
Originally-landed-as: 297297.386@safari-7622-branch (70a1e97f4ce6).
rdar://164277522
Canonical link: https://commits.webkit.org/302926@main
Commit: e9b2e94578123a7cb9130a7be0143ce1f0a12eac
https://github.com/WebKit/WebKit/commit/e9b2e94578123a7cb9130a7be0143ce1f0a12eac
Author: Sihui Liu <[email protected]>
Date: 2025-11-12 (Wed, 12 Nov 2025)
Changed paths:
M Source/WebKit/Platform/IPC/Connection.cpp
Log Message:
-----------
Stop using raw pointer in syncMessageStateMap()
https://bugs.webkit.org/show_bug.cgi?id=298489
rdar://156584462
Reviewed by Chris Dumez.
Connection::SyncMessageStateRelease::operator() only removes entry from
syncMessageStateMap() if instance's dispatcher
is not null (i.e. dispatcher has not been destroyed). This means if dispatcher
is destroyed, the map would keep a
dangling pointer that is not to be removed.
* Source/WebKit/Platform/IPC/Connection.cpp:
Originally-landed-as: 297297.390@safari-7622-branch (cef844c4512c).
rdar://164277284
Canonical link: https://commits.webkit.org/302927@main
Commit: ef9304e0e82bf30459af19381a690f0601b5687d
https://github.com/WebKit/WebKit/commit/ef9304e0e82bf30459af19381a690f0601b5687d
Author: Vassili Bykov <[email protected]>
Date: 2025-11-12 (Wed, 12 Nov 2025)
Changed paths:
M Source/JavaScriptCore/wasm/WasmGlobal.h
M Source/JavaScriptCore/wasm/WasmTable.cpp
M Source/JavaScriptCore/wasm/WasmTable.h
M Source/JavaScriptCore/wasm/WasmTypeDefinition.h
M Source/JavaScriptCore/wasm/WasmTypeDefinitionInlines.h
Log Message:
-----------
Retain the TypeDefinition underlying the Wasm::Type in Wasm::Global and
Wasm::Table
https://bugs.webkit.org/show_bug.cgi?id=297958
rdar://159278266
Reviewed by Yusuke Suzuki.
Wasm::Global and Wasm::Table both have a field containing a Wasm::Type
describing the
value of the global or the contents of the table. Wasm::Type has a field
`index` of type
`TypeIndex`. Formally, `TypeIndex` is an alias for `uintptr_t`. However, the
field may
actually be a pointer to the `TypeDefinition` instance corresponding to the
type.
Because TypeDefinitions are refcounted but Wasm::Type contains a raw unmanaged
pointer, it
is possible for a pointer in Wasm::Type to outlive the TypeDefinition it points
to. This
can happen with Wasm Globals and Tables because an exported global or a table
(if it's
empty) may outlive their associated Wasm instance when they are retained by
JavaScript
code. In that situation TypeDefinitions referenced by the instance may be
garbage-collected while pointers to them from the globals or tables still
exist. After
that, an attempt to set the value of the global or a table entry will
dereference the
dangling pointer as the value is validated against the type of the global or
the table.
This patch adds an explicit counted TypeDefinition reference to Wasm::Global
and Wasm::Table to ensure the TypeDefinition lives long enough.
Ideally, we might want to redesign Wasm::Type to have it carry a proper counted
reference
to its TypeDefinition instead of a disguised raw pointer. But that is a larger
undertaking, while in the meantime this patch fixes the known vulnerability.
Originally-landed-as: 297297.393@safari-7622-branch (b3e1519a9399).
rdar://164277125
Canonical link: https://commits.webkit.org/302928@main
Compare: https://github.com/WebKit/WebKit/compare/c974c3ab679d...ef9304e0e82b
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
