Cherry-pick 305413.548@safari-7624-branch — Web Locks origin validation

49c4af0

+bool WebProcessProxy::hasCommittedClientOrigin(const WebCore::ClientOrigin& clientOrigin) const
+{
+    return m_committedClientOrigins.contains(clientOrigin);
+}
+void WebProcessProxy::didCommitLoadClientOrigin(const WebCore::ClientOrigin& clientOrigin)
+{
+    m_committedClientOrigins.add(clientOrigin);
+}

The Web Locks API (navigator.locks) gives pages named, origin-scoped mutexes managed by a registry in the UI process (WebLockRegistryProxy). Renderers reach the registry via IPC, sending their ClientOrigin in the message. Because IPC from a compromised renderer is untrusted, the UI process must independently verify that the claimed origin is one that legitimately loaded in that process.

This commit closes an IPC origin-spoofing hole. WebFrameProxy::didCommitLoad now records each ClientOrigin into WebProcessProxy::m_committedClientOrigins, and WebLockRegistryProxy::requestLock (plus releaseLock, abortLockRequest, snapshot, clientIsGoingAway) validates that any claimed origin was actually committed by that web process before acting on it. Pre-fix, no such check existed — the UI process accepted whatever origin the renderer declared.

Significance

Before this fix, a compromised renderer could forge any ClientOrigin in a lock request, allowing it to acquire, block, or inspect locks belonging to completely different origins.

Audit directions

• Coverage completeness. The commit touches requestLock, releaseLock, abortLockRequest, snapshot, and clientIsGoingAway. Verify all five are uniformly gated — any missed handler is a bypass.
• Special-origin edge cases. Blob URL frames inherit the parent origin; data URL frames get opaque origins. Verify these are correctly recorded in didCommitLoad and that the committed-origins set uses the right equality semantics for opaque origins.
• Worker contexts. Service workers and shared workers don't go through WebFrameProxy::didCommitLoad the same way. Verify their origin registration path feeds into the same committedOrigins set or has separate equivalent validation.
• Lifetime/cleanup. When a frame navigates away, is the old ClientOrigin removed from the committed set, or does it persist for process lifetime? Persisting stale origins post-navigation could allow a renderer to retain lock access it should have lost.
• TOCTOU window. A race between didCommitLoad recording the origin and the lock IPC arriving is theoretically possible. Examine whether validation is done on the main UI-process thread where commits are also recorded.

---