← WebKit — 2026-W36
2507145cc7b12665dad36410b6031fdd1b3490ce ResourceLoadNotifier::dispatchWillSendRequest re-reads m_frame instead of the cached frame local
severity low
class UAF
confidence 0.5
signal score 9.17
Source/WebCore/loader
Primitive: Re-reading m_frame after a dispatchWillSendRequest client callout
Triage note: ResourceLoadNotifier::dispatchWillSendRequest switches the two post-callout accesses from m_frame-> to a locally held Ref frame, avoiding use of the member (and implicitly this) after the client callout that can run arbitrary code. Lifetime hardening but a small change whose concrete reachability is not shown.
Triage note: ResourceLoadNotifier::dispatchWillSendRequest switches the two post-callout accesses from m_frame-> to a locally held Ref frame, avoiding use of the member (and implicitly this) after the client callout that can run arbitrary code. Lifetime hardening but a small change whose concrete reachability is not shown.
Structural signals: smartptr_member_added (+4.87), msg_soft (+1.0), area:Source/WebCore/loader (+2.0), surgical (+1.3)
Commit message
ResourceLoadNotifier::dispatchWillSendRequest re-reads m_frame instead of the cached frame local
https://bugs.webkit.org/show_bug.cgi?id=322898
rdar://186149573
Reviewed by Chris Dumez.
dispatchWillSendRequest() already caches Ref frame = m_frame.get(), and
the ASSERT and every subsequent call go through that local, but two
documentLoader() lookups still dereferenced the m_frame member directly.
Route them through the cached frame for consistency; no behavior change.
As drive-by, remove `.get()` as well.
* Source/WebCore/loader/ResourceLoadNotifier.cpp:
(WebCore::ResourceLoadNotifier::dispatchWillSendRequest):
Canonical link: https://commits.webkit.org/320320@main
Before / after
Loading diff…
On This Page