Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ac6f65a8dc4b6d622435bee8f350aa64388ab7c5
https://github.com/WebKit/WebKit/commit/ac6f65a8dc4b6d622435bee8f350aa64388ab7c5
Author: Sihui Liu <[email protected]>
Date: 2026-09-14 (Mon, 14 Sep 2026)
Changed paths:
M Source/WebKit/UIProcess/BrowsingContextGroup.cpp
Log Message:
-----------
[Site Isolation] BrowsingContextGroup::addPage may create a remote page for a
terminated shared process
https://bugs.webkit.org/show_bug.cgi?id=323992
rdar://187228305
Reviewed by Per Arne Vollan.
Clearing the browsing context group's shared process is lazy.
processDidTerminate() does not touch m_sharedProcess, so
the pointer keeps referring to a terminated process until something calls
liveSharedProcess(), which is what notices the
terminated state and calls clearSharedProcess(). In the current implementation,
every place that needs the shared
process goes through the accessor liveSharedProcess(), except addPage(), which
reads m_sharedProcess directly.
Therefore, addPage() might create a RemotePageProxy for the terminated process
and call injectPageIntoNewProcess() on
it. The CreateWebPage message won't be sent successfully (since the process is
dead), but the RemotePageProxy is not
inert, as it joins m_remotePages -- forEachWebContentProcess() is a wrapper
around forEachRemotePage(), so the dead
process then participates in every page-wide fan-out, and hasRemotePages()
starts returning true, which makes
findString() take the multi-process aggregating path instead of the
single-process one. It is not a leak, since
removeFrameProcess() disconnects and drops the entries for a process once its
FrameProcess is destroyed, but
clearSharedProcess() does not touch m_remotePages, so the entry outlives the
clear.
Technically sending a message to the dead process should be a no-op: most of
those fan-outs use send(), which simply
fails, and when the send of a message with an async reply fails, the reply
handler is taken back and dispatched on the
main run loop with a null decoder, i.e. with default-constructed arguments
(Connection::sendMessageWithAsyncReply). So
the aggregating findString() path just gets a zero contribution from the dead
process, and there should be no
user-visible impact. This is more a consistency fix to make sure the states are
correct.
* Source/WebKit/UIProcess/BrowsingContextGroup.cpp:
(WebKit::BrowsingContextGroup::addPage):
Canonical link: https://commits.webkit.org/321100@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
