WebAVPlayerLayerView is a Cocoa (iOS/media) view used by WebCore’s fullscreen/video playback path; WebAVPlayerLayerView_dealloc is the custom deallocation function for that class. The view owns a videoView subview (accessible via the videoView property) that is added into the view hierarchy as a subview. Before the patch, dealloc tore down other state (e.g. the picture-in-picture player layer view via setValue:nil) but never explicitly detached or released the videoView from the view hierarchy first. The invariant being violated is that a subview which may hold back-references to, or be referenced elsewhere alongside, the layer view must be removed from its superview and cleared before the owning view is destroyed, so that no stale reference to the videoView (or to the dying player layer view through it) survives deallocation. Leaving the videoView attached during dealloc means the subview could remain in the hierarchy / retained by AVKit or layer machinery after its owner is gone, or be torn down in an unexpected order, yielding a use-after-free or inconsistent state when the video/fullscreen teardown races with page-driven destruction.

The fix, at the top of dealloc, retains the videoView into a RetainPtr, calls setVideoView:nil to clear the owner’s reference, removeFromSuperview to detach it from the hierarchy, and then drops the RetainPtr (videoView = nil) so the subview is released in a controlled order before the rest of dealloc proceeds. Because the vulnerable ordering/ownership detail lives largely in AVKit and the surrounding fullscreen controller (not shown in this one-file diff), the precise object whose freed memory is later accessed is an inference; what the patch establishes is that videoView was not being cleanly detached and released during the player layer view’s own deallocation, which is consistent with the reported unexpected process crash from malicious web content driving video/fullscreen lifecycle.

The diff shows a lifetime/ownership fix in an Objective-C dealloc that detaches and releases a subview before destroying its owner, which is the classic remedy for a use-after-free or premature-free during teardown; the reported effect is an unexpected process crash. This code runs in the process that hosts media/fullscreen playback (WebContent, or a media/GPU-adjacent context depending on port/configuration), so the corruption is confined to that sandboxed process. Realistically this is a controlled crash / potential UAF; escalation to code execution would require reliable heap grooming to reoccupy the freed object and is not demonstrated by the patch — that escalation reasoning is standard exploitation background, not something the commit establishes.