Branch: refs/heads/safari-7617.1.11.13-branch Home: https://github.com/WebKit/WebKit Commit: e79a011f4c8563bd3bbbc058cea44cd66b0161f1 https://github.com/WebKit/WebKit/commit/e79a011f4c8563bd3bbbc058cea44cd66b0161f1 Author: Dan Robson <dtr_bugzi...@apple.com> Date: 2023-10-16 (Mon, 16 Oct 2023)
Changed paths: M Configurations/Version.xcconfig Log Message: ----------- Versioning. WebKit-7617.1.11.13.1 Canonical link: https://commits.webkit.org/267815.307@safari-7617.1.11.13-branch Commit: fc1f3b2d0b64f876458acd44bf3781839a29104f https://github.com/WebKit/WebKit/commit/fc1f3b2d0b64f876458acd44bf3781839a29104f Author: Alex Christensen <achristen...@apple.com> Date: 2023-10-16 (Mon, 16 Oct 2023) Changed paths: M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h M Source/WebKit/NetworkProcess/webrtc/NetworkMDNSRegister.cpp M Source/WebKit/NetworkProcess/webrtc/NetworkMDNSRegister.h Log Message: ----------- Cherry-pick bfba0fe93995. rdar://116272449 Use smart pointers in NetworkMDNSRegister https://bugs.webkit.org/show_bug.cgi?id=262942 rdar://116272449 Reviewed by Youenn Fablet. Use std::unique_ptr that calls DNSServiceRefDeallocate automatically. Use CheckedRef for m_connection. The DNSRecordRef on PendingRegistrationRequest wasn't used. * Source/WebKit/NetworkProcess/webrtc/NetworkMDNSRegister.cpp: (WebKit::NetworkMDNSRegister::DNSServiceDeallocator::operator() const): (WebKit::NetworkMDNSRegister::unregisterMDNSNames): (WebKit::NetworkMDNSRegister::closeAndForgetService): (WebKit::NetworkMDNSRegister::registerMDNSName): (WebKit::NetworkMDNSRegister::sessionID const): (WebKit::NetworkMDNSRegister::~NetworkMDNSRegister): Deleted. * Source/WebKit/NetworkProcess/webrtc/NetworkMDNSRegister.h: Canonical link: https://commits.webkit.org/269166@main Identifier: 267815.308@safari-7617.1.11.13-branch Commit: 766247c4fd9fb5132c0dd573df7ef1ce56ef2336 https://github.com/WebKit/WebKit/commit/766247c4fd9fb5132c0dd573df7ef1ce56ef2336 Author: Alex Christensen <achristen...@apple.com> Date: 2023-10-16 (Mon, 16 Oct 2023) Changed paths: M Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm Log Message: ----------- Cherry-pick 80c45a1e6ff2. rdar://113527046 Fix crashes from hardening _WKRemoteObjectRegistry decoding https://bugs.webkit.org/show_bug.cgi?id=262983 rdar://113527046 Reviewed by David Kilzer. In April 2023, I made _WKRemoteObjectRegistry deserialization stricter by not allowing subclasses of the specified class to be deserialized. To make this transition as smooth as possible, I added a set of common and safe always-allowed subclasses including NSMutableString and several others. Telemetry indicates this increased the crash rate and this is to bring that crash rate back down. After analyzing 100% of the recent crash reports with useful data, I found 4 things that will help: 1. Allowing a class named "NSDecimalNumberPlaceholder" which is a subclass of NSDecimalNumber that some internal frameworks apparently use and give to Safari in a path that serializes it. Allow this. 2. Some crash logs indicate that NSDate objects are failing to decode because they are not in the set of allowed classes. There are some JS to ObjC object converters (such as the one used in WKWebView.callAsyncJavaScript) that can produce an NSDate, and this is ok and safe. Allow this too. 3. There are logs that indicate that sometimes a class is being sent from one process to another, and the receiving process has not loaded the dylib containing the ObjC class so the ObjC runtime can't find it. Add telemetry to get this class name for future diagnosis. 4. There are logs that indicate that sometimes a class is being sent that does not conform to NSSecureCoding according to NSCoder. Also add telemetry to get this class name for future diagnosis, but in this case I needed to add a @try/@catch because validateClassSupportsSecureCoding either returns YES or throws an ObjC exception, so to get the class name to CRASH_WITH_INFO I need to catch. * Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm: (alwaysAllowedClasses): (validateClass): (decodeObject): Canonical link: https://commits.webkit.org/269185@main Identifier: 267815.309@safari-7617.1.11.13-branch Commit: a9d12e2709a8e41f5f3b9121b453404a3c34e0a2 https://github.com/WebKit/WebKit/commit/a9d12e2709a8e41f5f3b9121b453404a3c34e0a2 Author: Nisha Jain <nisha_j...@apple.com> Date: 2023-10-16 (Mon, 16 Oct 2023) Changed paths: A LayoutTests/fast/text/crash-grapheme-cluster-spanning-adjacent-textitems-expected.txt A LayoutTests/fast/text/crash-grapheme-cluster-spanning-adjacent-textitems.html M Source/WebCore/layout/formattingContexts/inline/IntrinsicWidthHandler.cpp Log Message: ----------- Cherry-pick c36c90217951. rdar://115842183 jsc_fuz/wktr: RELEASE_ASSERT(to <= inlineTextItem.end()); in WebCore::Layout::TextUtil::width(...) (TextUtil.cpp:96). https://bugs.webkit.org/show_bug.cgi?id=262799 rdar://115842183. Reviewed by Alan Baradlay. Modified IntrinsicWidthHandler::simplifiedMinimumWidth() API to calculate width for grapheme-clusters spanning adjacent inline textitems. Test : fast/text/crash-grapheme-cluster-spanning-adjacent-textitems.html. * Source/WebCore/layout/formattingContexts/inline/IntrinsicWidthHandler.cpp : Changing API to consider grapheme-clusters spanning adjacent inline textitems. * LayoutTests/fast/text/crash-grapheme-cluster-spanning-adjacent-textitems.html : Added test case. * LayoutTests/fast/text/crash-grapheme-cluster-spanning-adjacent-textitems-expected.html : Added test expected file. Canonical link: https://commits.webkit.org/269276@main Identifier: 267815.310@safari-7617.1.11.13-branch Commit: 1d3a1c10b459d2851f7d0b963833816fb2abc03b https://github.com/WebKit/WebKit/commit/1d3a1c10b459d2851f7d0b963833816fb2abc03b Author: Vitor Roriz <vitor.ro...@apple.com> Date: 2023-10-16 (Mon, 16 Oct 2023) Changed paths: M Source/WebCore/PAL/pal/Logging.h M Source/WebCore/PAL/pal/text/TextCodecUTF8.cpp M Source/WebCore/PAL/pal/text/TextCodecUTF8.h M Source/WebCore/PAL/pal/text/TextEncodingRegistry.cpp Log Message: ----------- Cherry-pick 7d0bddb8572f. rdar://110454455 Speculative fix for crash at WebCore: PAL::newTextCodec https://bugs.webkit.org/show_bug.cgi?id=263084 rdar://110454455 Reviewed by Chris Dumez. This is a speculative fix for CrashTracer: com.apple.WebKit.WebContent at WebCore: PAL::newTextCodec. Text encodings work with the use of 2 static maps: - Name map, TextEncodingNameMap: maps encoding names to a canonical encoding name. - Codec map, TextCodecMap: maps canonical encoding names to a function that creates the desired codec. All possible canonical name has an entry in the map. When a TextEncoding object is created, it receives a string name that is transformed in a canonical name by atomCanonicalTextEncodingName(). A TextEncoding name can only be null, in which case it is not valid, or a valid canonical name. Therefore, it should not be possible to create a valid name which is not canonical. When a canonical name is being created, we populate both Name and Codec maps. First we try to populate them with a reduced set (buildBaseTextCodecMaps()), if not sufficient we populate them with an extended set (extendTextCodecMaps()). Since it is not possible to create a valid non-canonical name and that all canonical names have an entry in the Codec maps, it should not be possible to have no entry in the Codec map for a valid TextEncoding, i.e. a TextEncoding with a valid name. For that reason, the callers of newTextCodec() only assert that m_encoding, which is a TextEncoding, isValid(). This should theoretically be enough, but since it is crashing, it is not. The crash seems to happen because we are trying to deref a value from the TextEncodingNameMap that is null, that can happen if: [1]. we hace an entry for the encoding name in the map but the value is null. [2]. we have a valid encoding name that has no entry in the codec map. [1] is most likely not what is happening because we would need: 1.a: Having one of the functions that populate the codec maps (registerCodecs()) registering a null value. This shouldn't be possible becuse all of these function register lambda functions. 1.b: race-condition: This could also happen if we would get a valid entry in the map and between this point in time and the time we access the value of such iterator, the entry would be invalidated. That also shouldn't be possible, because all functions that mutate/access the maps are guarded by a static lock (encodingRegistryLock). [2] For testing this hypothesis, I've forced WebKit to populate the name and codec maps in the extended version, so I could verify a state in which all possible canonical names (and its codecs) are registered. I've then checked that in fact there is no canonical name without an entry in the codec map. Therefore, theoretically this should also be ruled out. As I haven't found a valid hypothesis for now, and also as I can't reproduce this issue, I'm trying a speculative fix, in which, we no longer just assert that m_encoding is valid and assume that there will be a an entry for it on the codec map. Instead, newTextCodec() will prevent a null deref by returning a default UTF-8 codec for: - a invalid encoding - if there is no entry for a valid encoding in the codec map - if there is an entry for a valid encoding in the codec map, but that entry has a null value. We also generate proper log that will help on further investigation. * Source/WebCore/PAL/pal/Logging.h: * Source/WebCore/PAL/pal/text/TextCodecUTF8.cpp: (PAL::TextCodecUTF8::codec): (PAL::TextCodecUTF8::registerCodecs): * Source/WebCore/PAL/pal/text/TextCodecUTF8.h: * Source/WebCore/PAL/pal/text/TextEncodingRegistry.cpp: (PAL::newTextCodec): Canonical link: https://commits.webkit.org/269304@main Identifier: 267815.311@safari-7617.1.11.13-branch Commit: b098d2f69931aaed762fbdcb1bade6d18e64d694 https://github.com/WebKit/WebKit/commit/b098d2f69931aaed762fbdcb1bade6d18e64d694 Author: Myah Cobbs <mco...@apple.com> Date: 2023-10-16 (Mon, 16 Oct 2023) Changed paths: M Source/WebCore/PAL/pal/Logging.h M Source/WebCore/PAL/pal/text/TextCodecUTF8.cpp M Source/WebCore/PAL/pal/text/TextCodecUTF8.h M Source/WebCore/PAL/pal/text/TextEncodingRegistry.cpp Log Message: ----------- Revert "Cherry-pick 7d0bddb8572f. rdar://110454455" This reverts commit 1d3a1c10b459d2851f7d0b963833816fb2abc03b. Identifier: 267815.312@safari-7617.1.11.13-branch Commit: 1d5fdc3cf72dda3bede6f4ea1d59263e8302be6a https://github.com/WebKit/WebKit/commit/1d5fdc3cf72dda3bede6f4ea1d59263e8302be6a Author: Myah Cobbs <mco...@apple.com> Date: 2023-10-16 (Mon, 16 Oct 2023) Changed paths: R LayoutTests/fast/text/crash-grapheme-cluster-spanning-adjacent-textitems-expected.txt R LayoutTests/fast/text/crash-grapheme-cluster-spanning-adjacent-textitems.html M Source/WebCore/layout/formattingContexts/inline/IntrinsicWidthHandler.cpp Log Message: ----------- Revert "Cherry-pick c36c90217951. rdar://115842183" This reverts commit a9d12e2709a8e41f5f3b9121b453404a3c34e0a2. Identifier: 267815.313@safari-7617.1.11.13-branch Commit: ef7a3d7794abb71a2026b56396123a3e91a9b8e4 https://github.com/WebKit/WebKit/commit/ef7a3d7794abb71a2026b56396123a3e91a9b8e4 Author: Myah Cobbs <mco...@apple.com> Date: 2023-10-16 (Mon, 16 Oct 2023) Changed paths: M Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm Log Message: ----------- Revert "Cherry-pick 80c45a1e6ff2. rdar://113527046" This reverts commit 766247c4fd9fb5132c0dd573df7ef1ce56ef2336. Identifier: 267815.314@safari-7617.1.11.13-branch Commit: 5283e3e311fbb519598d62a5f5c674bb979da6b5 https://github.com/WebKit/WebKit/commit/5283e3e311fbb519598d62a5f5c674bb979da6b5 Author: Myah Cobbs <mco...@apple.com> Date: 2023-10-16 (Mon, 16 Oct 2023) Changed paths: M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h M Source/WebKit/NetworkProcess/webrtc/NetworkMDNSRegister.cpp M Source/WebKit/NetworkProcess/webrtc/NetworkMDNSRegister.h Log Message: ----------- Revert "Cherry-pick bfba0fe93995. rdar://116272449" This reverts commit fc1f3b2d0b64f876458acd44bf3781839a29104f. Identifier: 267815.315@safari-7617.1.11.13-branch Commit: 58eefd20f90161ff7ecd37d6e5af672354cb5ebd https://github.com/WebKit/WebKit/commit/58eefd20f90161ff7ecd37d6e5af672354cb5ebd Author: Alex Christensen <achristen...@apple.com> Date: 2023-10-16 (Mon, 16 Oct 2023) Changed paths: M Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm Log Message: ----------- Cherry-pick 80c45a1e6ff2. rdar://113527046 Fix crashes from hardening _WKRemoteObjectRegistry decoding https://bugs.webkit.org/show_bug.cgi?id=262983 rdar://113527046 Reviewed by David Kilzer. In April 2023, I made _WKRemoteObjectRegistry deserialization stricter by not allowing subclasses of the specified class to be deserialized. To make this transition as smooth as possible, I added a set of common and safe always-allowed subclasses including NSMutableString and several others. Telemetry indicates this increased the crash rate and this is to bring that crash rate back down. After analyzing 100% of the recent crash reports with useful data, I found 4 things that will help: 1. Allowing a class named "NSDecimalNumberPlaceholder" which is a subclass of NSDecimalNumber that some internal frameworks apparently use and give to Safari in a path that serializes it. Allow this. 2. Some crash logs indicate that NSDate objects are failing to decode because they are not in the set of allowed classes. There are some JS to ObjC object converters (such as the one used in WKWebView.callAsyncJavaScript) that can produce an NSDate, and this is ok and safe. Allow this too. 3. There are logs that indicate that sometimes a class is being sent from one process to another, and the receiving process has not loaded the dylib containing the ObjC class so the ObjC runtime can't find it. Add telemetry to get this class name for future diagnosis. 4. There are logs that indicate that sometimes a class is being sent that does not conform to NSSecureCoding according to NSCoder. Also add telemetry to get this class name for future diagnosis, but in this case I needed to add a @try/@catch because validateClassSupportsSecureCoding either returns YES or throws an ObjC exception, so to get the class name to CRASH_WITH_INFO I need to catch. * Source/WebKit/Shared/API/Cocoa/WKRemoteObjectCoder.mm: (alwaysAllowedClasses): (validateClass): (decodeObject): Canonical link: https://commits.webkit.org/269185@main Identifier: 267815.316@safari-7617.1.11.13-branch Commit: 999d594f33837b89bee8d3b9d7f9542eb5f61be7 https://github.com/WebKit/WebKit/commit/999d594f33837b89bee8d3b9d7f9542eb5f61be7 Author: Myah Cobbs <mco...@apple.com> Date: 2023-10-17 (Tue, 17 Oct 2023) Changed paths: M Configurations/Version.xcconfig Log Message: ----------- Versioning. WebKit-7617.1.11.13.2 Identifier: 267815.317@safari-7617.1.11.13-branch Compare: https://github.com/WebKit/WebKit/compare/e79a011f4c85%5E...999d594f3383 To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications _______________________________________________ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes