Branch: refs/heads/webkitglib/2.48
Home: https://github.com/WebKit/WebKit
Commit: f7f6cde269578821ad4f4012ccf1905d7a271a5d
https://github.com/WebKit/WebKit/commit/f7f6cde269578821ad4f4012ccf1905d7a271a5d
Author: Andy Estes <aes...@apple.com>
Date: 2025-07-15 (Tue, 15 Jul 2025)
Changed paths:
A LayoutTests/fast/parser/resources/xhtml-parser-pending-callbacks-crash.js
A LayoutTests/fast/parser/xhtml-parser-pending-callbacks-crash-expected.txt
A LayoutTests/fast/parser/xhtml-parser-pending-callbacks-crash.xhtml
M Source/WebCore/xml/parser/XMLDocumentParserLibxml2.cpp
Log Message:
-----------
Cherry-pick 297376@main (1d1b9f7f23d2).
https://bugs.webkit.org/show_bug.cgi?id=295946
Infinite recursion in XMLMalloc::free()
https://bugs.webkit.org/show_bug.cgi?id=295946
rdar://155829627
Reviewed by Chris Dumez.
XMLMalloc::free() calls xmlFree(), which in libxml2 is #defined to free().
This leads to infinite
recursion, since in this context XMLMalloc::free is resolved before ::free.
Fixed this by doing
what we already do for XMLMalloc::malloc(): created a helper function named
xmlFreeHelper() that
calls xmlFree().
Added a layout test.
*
LayoutTests/fast/parser/resources/xhtml-parser-pending-callbacks-crash.js:
Added.
*
LayoutTests/fast/parser/xhtml-parser-pending-callbacks-crash-expected.txt:
Added.
* LayoutTests/fast/parser/xhtml-parser-pending-callbacks-crash.xhtml: Added.
* Source/WebCore/xml/parser/XMLDocumentParserLibxml2.cpp:
(WebCore::xmlFreeHelper):
(WebCore::XMLMalloc::free):
Canonical link: https://commits.webkit.org/297376@main
Canonical link: https://commits.webkit.org/290945.276@webkitglib/2.48
Commit: a6f7e7b5979b72c8f6a08f26f0963ed38188c1c2
https://github.com/WebKit/WebKit/commit/a6f7e7b5979b72c8f6a08f26f0963ed38188c1c2
Author: David Kilzer <ddkil...@apple.com>
Date: 2025-07-15 (Tue, 15 Jul 2025)
Changed paths:
M Source/WebCore/xml/parser/XMLDocumentParserLibxml2.cpp
Log Message:
-----------
Cherry-pick 297381@main (e4ffdc6cd723).
https://bugs.webkit.org/show_bug.cgi?id=295960
WebCore::XMLMalloc::free() calls itself when xmlFree() is defined to call
libmalloc free()
<https://bugs.webkit.org/show_bug.cgi?id=295960>
<rdar://155844722>
Reviewed by Jonathan Bedard.
* Source/WebCore/xml/parser/XMLDocumentParserLibxml2.cpp:
(WebCore::xmlFreeHelper):
- Change call to xmlFree() to ::xmlFree() so that if a macro
replaces xmlFree() with a call to libmalloc free(), the compiler
won't try to call WebCore::XMLMalloc::free() recursively.
Canonical link: https://commits.webkit.org/297381@main
Canonical link: https://commits.webkit.org/290945.277@webkitglib/2.48
Commit: e6b245323fc924b9ba07576185fea8df7254242a
https://github.com/WebKit/WebKit/commit/e6b245323fc924b9ba07576185fea8df7254242a
Author: Wenson Hsieh <wenson_hs...@apple.com>
Date: 2025-07-15 (Tue, 15 Jul 2025)
Changed paths:
M Source/WebKit/Shared/ScriptTelemetry.cpp
Log Message:
-----------
Cherry-pick 297362@main (e5e6aadcb027).
https://bugs.webkit.org/show_bug.cgi?id=295914
[Safari 26] Mitigate an occasional crash underneath
WebKit::initializeFilterRules
https://bugs.webkit.org/show_bug.cgi?id=295914
rdar://153031203
Reviewed by Aditya Keerthi and Richard Robinson.
Mitigate a web content process crash when attempting to initialize
`ScriptTrackingPrivacyFilter`,
due to trying to add a null or empty string as a hash key. It's unclear how
a list rule with an
empty host name could be possible (and there are no reproduction steps), so
just harden the web-
process-side logic against this possibility for now (leaving behind a debug
assertion).
* Source/WebKit/Shared/ScriptTrackingPrivacyFilter.cpp:
(WebKit::initializeFilterRules):
Canonical link: https://commits.webkit.org/297362@main
Canonical link: https://commits.webkit.org/290945.278@webkitglib/2.48
Commit: ac5765cc2a07a0e5a41d692a753c7ddc602b2e02
https://github.com/WebKit/WebKit/commit/ac5765cc2a07a0e5a41d692a753c7ddc602b2e02
Author: Abrar Rahman Protyasha <a_protya...@apple.com>
Date: 2025-07-15 (Tue, 15 Jul 2025)
Changed paths:
M Source/WebCore/page/EventHandler.cpp
Log Message:
-----------
Cherry-pick 297345@main (30a90c6902be).
https://bugs.webkit.org/show_bug.cgi?id=295900
WeakPtr<Page> null dereference crash under
EventHandler::handleMouseReleaseEvent
https://bugs.webkit.org/show_bug.cgi?id=295900
rdar://154193932
Reviewed by Wenson Hsieh.
Recently, we have observed some null dereference crashes under
EventHandler::handleMouseReleaseEvent(), all of the nature:
```
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000008
Exception Codes: 0x0000000000000001, 0x0000000000000008
WebCore::Page::WeakValueType*
WTF::WeakPtrImplBase<WTF::DefaultWeakPtrImpl>::get<WebCore::Page>()
WTF::WeakPtr<WebCore::Page, WTF::DefaultWeakPtrImpl,
WTF::RawPtrTraits<WTF::DefaultWeakPtrImpl>>::get() const
WebCore::Frame::protectedPage() const
WebCore::EventHandler::handleMouseReleaseEvent(WebCore::PlatformMouseEvent
const&)
```
... which indicates that `WeakPtr<Page>` in `EventHandler::m_frame`
is holding on to a nullptr. Instead of unconditionally accessing this
object, this patch makes the codepath less crash prone by introducing a
null check.
No new tests because I was not able to create a reproduction for the
crash yet.
* Source/WebCore/page/EventHandler.cpp:
(WebCore::EventHandler::handleMouseReleaseEvent):
Canonical link: https://commits.webkit.org/297345@main
Canonical link: https://commits.webkit.org/290945.279@webkitglib/2.48
Compare: https://github.com/WebKit/WebKit/compare/d626938b8f06...ac5765cc2a07
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
