Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 89d4e73db3539c113f7a055eb95652dd83795ec0
https://github.com/WebKit/WebKit/commit/89d4e73db3539c113f7a055eb95652dd83795ec0
Author: Chris Dumez <[email protected]>
Date: 2026-07-15 (Wed, 15 Jul 2026)
Changed paths:
M Source/WebKit/Platform/IPC/Connection.cpp
Log Message:
-----------
REGRESSION(316617@main): Use-after-free in
IPC::Connection::SyncMessageState::~SyncMessageState()
https://bugs.webkit.org/show_bug.cgi?id=319349
rdar://181691990
Reviewed by Ben Nham.
316617@main added incomingMessagesLocker.unlockEarly() /
waitForMessagesLocker.unlockEarly()
to the async-reply-with-dispatcher branch of
Connection::processIncomingMessage() so the reply
handler would run without the locks held (matching the other branches and
avoiding
re-entrancy). However, the `RefPtr syncState = m_syncState` local declared
earlier in the
function is destroyed *before* those lockers at the return (reverse declaration
order), so this
change moved the final SyncMessageState deref -- and the ~SyncMessageState() it
can trigger --
out from under m_incomingMessagesLock on a hot path (every async reply,
including GPUProcess
sendWithAsyncReply replies).
SyncMessageState is shared per-SerialFunctionDispatcher
(SyncMessageState::getOrCreate()), so a
single instance is kept alive by the m_syncState of every Connection bound to
that dispatcher
(e.g. the main UIProcess connection and the RemoteRenderingBackendProxy
GPUProcess connection).
Connection::invalidate() drops its m_syncState reference under
m_incomingMessagesLock on the
dispatcher thread. That lock is what serialized the "read m_syncState, use it,
drop it" section
on the connection work queue against invalidate(). With the last deref now
running unlocked, the
work-queue thread's ~SyncMessageState() can race invalidate()'s teardown of the
same shared
object, producing the heap-use-after-free reported by ASan during WebPage
teardown
(~WebPage -> ~RemoteRenderingBackendProxy -> disconnectGPUProcess ->
Connection::invalidate).
Fix this by dropping our SyncMessageState reference (syncState = nullptr) while
still holding
m_incomingMessagesLock, before unlockEarly(), in both async-reply branches.
This preserves
316617@main's intent of running the reply handler unlocked while restoring the
pre-regression
ordering. The completion handler does not need syncState.
* Source/WebKit/Platform/IPC/Connection.cpp:
(IPC::Connection::processIncomingMessage):
Canonical link: https://commits.webkit.org/317220@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications