Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 8fa37140295aadfa570ade74c08137279bc16a73
https://github.com/WebKit/WebKit/commit/8fa37140295aadfa570ade74c08137279bc16a73
Author: Kristian Monsen <[email protected]>
Date: 2026-09-09 (Wed, 09 Sep 2026)
Changed paths:
A LayoutTests/ipc/cocoa/sectrust-null-data-crash-expected.txt
A LayoutTests/ipc/cocoa/sectrust-null-data-crash.html
M LayoutTests/platform/ios-18/TestExpectations
M LayoutTests/platform/mac-sequoia/TestExpectations
M Source/WebKit/Shared/cf/CoreIPCSecTrust.mm
Log Message:
-----------
CoreIPCSecTrust::createSecTrust() inserts nil into an NSMutableDictionary for
an empty CoreIPCData
https://bugs.webkit.org/show_bug.cgi?id=323638
rdar://185199834
Reviewed by Abrar Rahman Protyasha.
CoreIPCData's dataReference is serialized as std::optional<std::span<const
uint8_t>>, so a
malformed IPC message can decode a CoreIPCData whose m_cfData is null, making
CoreIPCData::toID() return nil. createSecTrust() inserted that nil into the
SecTrust property
list dictionary, and -[NSMutableDictionary setObject:forKey:] raises
NSInvalidArgumentException, terminating the receiving process. Since a
SecTrustRef is decoded
by calling createSecTrust() directly, any message carrying a
WebCore::CertificateInfo lets a
compromised WebContent process take down the UI or Network process.
A null value has no representation in a SecTrust property list, so reject the
whole trust
object instead of inserting nil or silently dropping the entry, which would
build a property
list that does not match the wire data. All callers of createSecTrust() already
handle a null
return; the generated coder returns it for a disengaged optional, and the
existing
SecTrustCreateFromPropertyListRepresentation error path returns it too.
CoreIPCData is the only nil source here: CoreIPCString::toID() returns @"" for
a null String,
and CoreIPCNumber and CoreIPCDate always produce an object, so guarding the
dictionary values
and array elements built from a CoreIPCData covers every insertion. The encode
side always
constructs CoreIPCData from a class-checked NSData, so no legitimate trust
object can reach
the new early returns.
The four sites that already null-checked logged and continued with the element
skipped; they
now reject too, and their ASSERT_NOT_REACHED() is dropped since this input is
attacker
controlled and reaching it is not a WebKit bug.
Test: ipc/cocoa/sectrust-null-data-crash.html
* LayoutTests/ipc/cocoa/sectrust-null-data-crash-expected.txt: Added.
* LayoutTests/ipc/cocoa/sectrust-null-data-crash.html: Added.
* LayoutTests/platform/ios-18/TestExpectations:
* LayoutTests/platform/mac-sequoia/TestExpectations:
* Source/WebKit/Shared/cf/CoreIPCSecTrust.mm:
(WebKit::appendDataObject):
(WebKit::createPolicyDictionary):
(WebKit::addToDictFromOptionalDataHelper):
(WebKit::CoreIPCSecTrust::createSecTrust const):
Canonical link: https://commits.webkit.org/320749@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
