This is a lifetime/frame-type logic bug in WebCore’s layout and back/forward cache code that manifests as a Safari (WebContent) crash. Two related invariants are restored. First, in LocalFrameView::setContentsSize(), the code fetched the owning Page via a raw pointer (Page* page = m_frame->page();) immediately after calling contentsResized(). contentsResized() can run layout work and dispatch notifications that re-enter WebCore and can tear down or detach the frame/page; using a raw Page* across that call risks reading a pointer that has been (or is about to be) invalidated, and the subsequent if (!page) return; cannot catch a dangling — as opposed to null — pointer.

The fix changes it to RefPtr page = m_frame->page();, which takes a strong reference so the Page stays alive for the remainder of the function, closing a use-after-free window. Second, in BackForwardCache::markPagesForContentsSizeChanged(), the code compared &page.mainFrame() to the cached page’s main-frame view’s frame. mainFrame() returns the abstract Frame, which under site isolation may be a RemoteFrame that has no LocalFrameView; the comparison (and the surrounding assumption that the main frame is local) is unsafe when the main frame is remote.

The fix uses page.localMainFrame(), which returns a LocalFrame* (null when the main frame is remote), so the comparison only matches a genuine local main frame and simply skips the mark when the main frame is remote, avoiding a bad access. Both edits are defensive: they don’t change intended behavior for the common local, live-page case but remove the paths where a suspended/cached page or a re-entrant contentsResized() left code operating on a freed or wrong-typed frame/page object. Given the diff is a raw-pointer-to-RefPtr hardening plus a local-main-frame guard, the crash is best characterized as a use-after-free / dangling-pointer condition rather than a pure null-deref.

As shown, the primitive is a use-after-free/dangling-pointer read reached through layout re-entrancy or a remote-main-frame mismatch, and the patch is a lifetime/type hardening rather than a bounds fix. In the general case a controlled UAF of a Page/Frame object could be groomed toward stronger corruption, but the diff itself only demonstrates a crash and gives no attacker-controlled write or allocation shaping, so realistic impact here is a denial-of-service crash confined to the WebContent (renderer) process inside the sandbox. Escalation to code execution is not established by this commit and would require additional primitives, consistent with the medium severity and “unexpected Safari crash” description.