[webkit-changes] [WebKit/WebKit] b5aab2: Cherry-pick 7d0bddb8572f. rdar://110454455
Ryosuke Niwa
noreply at github.com
Tue May 14 16:13:27 PDT 2024
Branch: refs/heads/safari-7617.1.11.10-branch
Home: https://github.com/WebKit/WebKit
Commit: b5aab2e35ff501e63672bd1d33eda4aa5732e052
https://github.com/WebKit/WebKit/commit/b5aab2e35ff501e63672bd1d33eda4aa5732e052
Author: Vitor Roriz <vitor.roriz at 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.307 at safari-7617.1.11.10-branch
Commit: bffca936f8ed2a475aaa34da3abf009ef9a825d7
https://github.com/WebKit/WebKit/commit/bffca936f8ed2a475aaa34da3abf009ef9a825d7
Author: Alex Christensen <achristensen at 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 at safari-7617.1.11.10-branch
Commit: 7c73c0b76f92c25373f2aabaeac28453f7822368
https://github.com/WebKit/WebKit/commit/7c73c0b76f92c25373f2aabaeac28453f7822368
Author: Alex Christensen <achristensen at 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 at safari-7617.1.11.10-branch
Commit: f3120243d8e741a32b5a2dd31ebf393aa20d0bd4
https://github.com/WebKit/WebKit/commit/f3120243d8e741a32b5a2dd31ebf393aa20d0bd4
Author: Nisha Jain <nisha_jain at 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 at safari-7617.1.11.10-branch
Commit: 586e5bbc91d751d783be8b4c6b901634148dc987
https://github.com/WebKit/WebKit/commit/586e5bbc91d751d783be8b4c6b901634148dc987
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-10-16 (Mon, 16 Oct 2023)
Changed paths:
M Source/WebCore/platform/network/NetworkStorageSession.h
Log Message:
-----------
Unreviewed build fix. rdar://116272449
Identifier: 267815.311 at safari-7617.1.11.10-branch
Commit: c5fec11fb6b8f012105cb40846019cc8724d6673
https://github.com/WebKit/WebKit/commit/c5fec11fb6b8f012105cb40846019cc8724d6673
Author: Myah Cobbs <mcobbs at 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 b5aab2e35ff501e63672bd1d33eda4aa5732e052.
Identifier: 267815.312 at safari-7617.1.11.10-branch
Commit: 959bb466dee95e5fad4d313fdb84114656ecdaca
https://github.com/WebKit/WebKit/commit/959bb466dee95e5fad4d313fdb84114656ecdaca
Author: Dan Robson <dtr_bugzilla at apple.com>
Date: 2023-10-16 (Mon, 16 Oct 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7617.1.11.10.1
Canonical link: https://commits.webkit.org/267815.313@safari-7617.1.11.10-branch
Commit: 8f35f8df97c779e3fa7bf91e7022935d03eb1dad
https://github.com/WebKit/WebKit/commit/8f35f8df97c779e3fa7bf91e7022935d03eb1dad
Author: Russell Epstein <repstein at apple.com>
Date: 2023-10-17 (Tue, 17 Oct 2023)
Changed paths:
M Configurations/Version.xcconfig
Log Message:
-----------
Versioning.
WebKit-7617.1.11.10.2
Canonical link: https://commits.webkit.org/267815.314@safari-7617.1.11.10-branch
Commit: c735dbaf464c05dbbeab5f5e23567ca23f70cee6
https://github.com/WebKit/WebKit/commit/c735dbaf464c05dbbeab5f5e23567ca23f70cee6
Author: Russell Epstein <repstein at apple.com>
Date: 2023-10-17 (Tue, 17 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
Canonical link: https://commits.webkit.org/267815.315@safari-7617.1.11.10-branch
Commit: 7e4369ec42866dc682a84956f8462770d82fdf8b
https://github.com/WebKit/WebKit/commit/7e4369ec42866dc682a84956f8462770d82fdf8b
Author: Myah Cobbs <mcobbs at apple.com>
Date: 2023-10-17 (Tue, 17 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 c735dbaf464c05dbbeab5f5e23567ca23f70cee6.
Identifier: 267815.316 at safari-7617.1.11.10-branch
Commit: 89afd99743cfaa90eb6928cd0f6425538765508f
https://github.com/WebKit/WebKit/commit/89afd99743cfaa90eb6928cd0f6425538765508f
Author: Simon Fraser <simon.fraser at apple.com>
Date: 2023-10-30 (Mon, 30 Oct 2023)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
Log Message:
-----------
Cherry-pick 6a3c5666d426. rdar://117079338
As a "preview" feature, content-visibility should be off by default
https://bugs.webkit.org/show_bug.cgi?id=263428
rdar://117079338
Reviewed by Wenson Hsieh.
269480 at main should have turned the feature off by default, and failed to do so.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
Canonical link: https://commits.webkit.org/269609@main
Identifier: 267815.317 at safari-7617.1.11.10-branch
Commit: e13c9d9be5e8b66aed9c6d14387875a72ef7a8f2
https://github.com/WebKit/WebKit/commit/e13c9d9be5e8b66aed9c6d14387875a72ef7a8f2
Author: Ryosuke Niwa <rniwa at webkit.org>
Date: 2023-10-30 (Mon, 30 Oct 2023)
Changed paths:
M Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml
Log Message:
-----------
Cherry-pick bf33b61e545e. rdar://117595888
Reenable requestIdleCallback by default in Apple's ports
https://bugs.webkit.org/show_bug.cgi?id=262551
Reviewed by Wenson Hsieh.
The memory regression seen in PLUM3 has been fixed as of https://commits.webkit.org/268782@main.
Re-enable requestIdleCallback in Apple's ports.
* Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml:
Canonical link: https://commits.webkit.org/268800@main
Identifier: 267815.318 at safari-7617.1.11.10-branch
Compare: https://github.com/WebKit/WebKit/compare/b5aab2e35ff5%5E...e13c9d9be5e8
To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications
More information about the webkit-changes
mailing list