[22] [WebKit] MessagePort lifecycle on NetworkProcess restart

Severity: Low | Component: MessagePort lifecycle | 67117c4

Rated Low because the diff adds a networkProcessCrashed symmetry to the MessagePort subsystem and a late-arrival guard in takeAllMessagesForPort; pre-fix, stranded ports tripped the anti-spoof MESSAGE_CHECK in the NetworkProcess after a Networking restart and terminated the WebContent process, but the impact is availability rather than a memory or trust-boundary primitive.

WebMessagePortChannelProvider::networkProcessCrashed forcibly detaches all locally-tracked ports and clears m_inProcessPortMessages. takeAllMessagesForPort gains a defensive late-arrival guard for worker-thread completions racing with detachment.

Source/WebCore/dom/messageports/WebMessagePortChannelProvider.cpp

+void WebMessagePortChannelProvider::networkProcessCrashed()
+{
+    for (auto& port : m_localPorts)
+        port.detach();
+    m_inProcessPortMessages.clear();
+}

Anti-spoof MESSAGE_CHECK firing on legitimate stranded ports after a Networking restart, killing the WebContent process.

Patch Details

A new networkProcessCrashed entry point makes the WebContent-side bookkeeping symmetric with the Networking-side. takeAllMessagesForPort rejects late completions cleanly.

Background

Message-port state is distributed across WebContent and Networking. A prior hardening commit (305413.547) added MESSAGE_CHECKs in the Networking process to reject unknown port IPC as a defense against spoofs from compromised WebContent — but those MESSAGE_CHECKs cannot distinguish "spoofed by compromised renderer" from "legitimate but stranded after my predecessor died".

Analysis

Pre-fix, when a MessageChannel was created, both endpoints were registered with the live Networking process via CreateNewMessagePortChannel / EntangleLocalPortInThisProcessToRemote. If the Networking process crashed/jetsam'd, the WebContent process would reconnect to a freshly spawned Networking process — but its MessagePort JS objects were still entangled and reachable. Subsequent port.postMessage IPCs would name port identifiers that the new Networking process had never seen, and the MESSAGE_CHECK would kill the WebContent process.

🔒

Why a hardening MESSAGE_CHECK in one process can become a self-inflicted DoS in another — and what the symmetric invalidation must look like.

Subscribe to read more

Audit directions

🔒

Four reusable patterns for finding receiver-side hardening that lacks a sender-side counterpart, with concrete grep targets across WebKit's multi-process clients.

Subscribe to read more