Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 1c2e7ba25b95c9835fdbd67878c189d7906c713a
https://github.com/WebKit/WebKit/commit/1c2e7ba25b95c9835fdbd67878c189d7906c713a
Author: Chris Dumez <[email protected]>
Date: 2026-07-21 (Tue, 21 Jul 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
NetworkConnectionToWebProcess::takeAllMessagesForPort terminates WebContent
on a benign message-port race
https://bugs.webkit.org/show_bug.cgi?id=319881
rdar://182244946
Reviewed by Brady Eidson.
A WebContent process asks the network process for the messages queued on one of
its
MessagePorts via NetworkConnectionToWebProcess::takeAllMessagesForPort(). That
request
can race with the port's channel being destroyed, or with the port being
disentangled /
transferred to another process: existingChannelContainingPort() returns null
once the
channel is gone, and MessagePortChannel::processForPort() returns std::nullopt
while a
port is mid-transfer or closed.
Both of these are benign races, not misbehaving WebContent processes, yet the
handler
treated them as invalid messages via MESSAGE_CHECK_COMPLETION(). Note that
MESSAGE_CHECK_COMPLETION() still calls
markCurrentlyDispatchedMessageAsInvalid(), so it
requests termination of the sender; the completion handler only avoids leaving
the reply
hanging. This is easy to hit while a SharedWorker's context process is being
torn down and
relaunched, since a takeAllMessagesForPort() may already have been dispatched
from a worker
thread (see the existing comments in MessagePort::messageAvailable() and
WebMessagePortChannelProvider::takeAllMessagesForPort()). When it happens
repeatedly, the
network process terminates each new WebContent process, the worker relaunches
(its clients
still need it), and the loop spins fast enough that the UI process accumulates
IPC::Connection
port rights until it is killed for Mach port exhaustion.
Only take messages when the port is currently entangled to the requesting
process. When the
channel is missing or the port is not entangled to anyone, gracefully return no
messages
instead of terminating the sender; the queued messages remain in the channel
and are
delivered once the port is re-entangled to its owner. Keep the terminating
check strictly for
a request for a port entangled to a *different* process, which is the only
genuine violation.
No new tests, I have tried writing one but wasn't successful. This is likely
very timing
dependent.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::takeAllMessagesForPort):
Canonical link: https://commits.webkit.org/317668@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
