============================================================================
 Crash captured on a clean (unmodified) Chromium ASAN build.
 Renderer process, ~12 seconds after page load.
 3 of 8 runs reproduced; all 3 hit the identical PC (chrome+0x35f1c08e)
 with the identical fault target (chrome+0x452072b0 = AbortSignal vtable).
============================================================================

Received signal 11 SEGV_ACCERR 55922cbaa2b0
#0 0x5591f87199f6 (/chromium/chromium/src/out/asan/chrome+0x10d769f5)
#1 0x55921092da98 (/chromium/chromium/src/out/asan/chrome+0x28f8aa97)
#2 0x5592108eb327 (/chromium/chromium/src/out/asan/chrome+0x28f48326)
#3 0x55921092ce9f (/chromium/chromium/src/out/asan/chrome+0x28f89e9e)
#4 0x7fb056840050 (/usr/lib/x86_64-linux-gnu/libc.so.6+0x3c04f)
#5 0x55921d8bf08f (/chromium/chromium/src/out/asan/chrome+0x35f1c08e)
#6 0x55922237bb7a (/chromium/chromium/src/out/asan/chrome+0x3a9d8b79)
#7 0x5592036bc7da (/chromium/chromium/src/out/asan/chrome+0x1bd197d9)
  r8: 000055921d8befd8  r9: 00007fffffffff01 r10: 00007bb0538c6600 r11: 00007bb0538c6600
 r12: 00007d30549e2168 r13: 00007b9c02090900 r14: 00000f760a6f6060 r15: 00007bb0537b0300
  di: 00007d30549e2180  si: 00000f760a6f606d  bp: 00007fffb62cd6b0  bx: 00007fffb62cd600
  dx: 00000ab245975456  ax: 000055922cbaa2b0  cx: 00007bb0537b03a0  sp: 00007fffb62cd600
  ip: 000055921d8bf08f efl: 0000000000010246 cgf: 002b000000000033 erf: 0000000000000007
 trp: 000000000000000e msk: 0000000000000000 cr2: 000055922cbaa2b0
[end of stack trace]

----------------------------------------------------------------------------
 Symbolized (llvm-symbolizer --obj=out/asan/chrome)
----------------------------------------------------------------------------

Signal handler chain (#0–#3):
  #0 0x10d769f5  __interceptor_backtrace
  #1 0x28f8aa97  base::debug::CollectStackTrace          base/debug/stack_trace_posix.cc:1050
  #2 0x28f48326  base::debug::StackTrace::StackTrace     base/debug/stack_trace.cc:280
  #3 0x28f89e9e  base::debug::StackDumpSignalHandler     base/debug/stack_trace_posix.cc:483
  #4 libc signal trampoline

Faulting frame:
  #5 0x35f1c08e  cppgc::internal::PersistentNode::InitializeAsUsedNode
                   v8/include/cppgc/internal/persistent-node.h:36:12
                   (owner_ = owner;  <-- wild WRITE)
                 inlined into cppgc::internal::PersistentRegionBase::TryAllocateNodeFromFreeList
                   v8/include/cppgc/internal/persistent-node.h:104
                 inlined into cppgc::internal::PersistentRegion::AllocateNode
                   v8/include/cppgc/internal/persistent-node.h:153
                 inlined into cppgc::internal::BasicPersistent<...>::BasicPersistent
                   v8/include/cppgc/persistent.h:78
                 inlined into blink::AbortSignal::timeout(ScriptState*, unsigned long)

  #6 0x3a9d8b79  blink::(anonymous namespace)::v8_abort_signal::TimeoutStaticOperationCallback
                   gen/third_party/blink/renderer/bindings/core/v8/v8_abort_signal.cc:251

  #7 0x1bd197d9  Builtins_CallApiCallbackOptimizedNoProfiling

----------------------------------------------------------------------------
 Interpretation
----------------------------------------------------------------------------
SEGV_ACCERR + cr2 == fault address == %rax: a write to a read-only page in
the chrome binary's .rodata segment. The instruction at persistent-node.h:36
is `owner_ = owner;` — the first store performed by InitializeAsUsedNode
on the node just popped from the PersistentRegion free list.

The fault address (chrome+0x452072b0) symbolizes to:
    vtable for blink::AbortSignal
i.e. the corrupted free list was walked
    used-PersistentNode → owner_ (BasicPersistent*) → raw_ (AbortSignal*) → vptr
and the write landed on the read-only vtable page.

That node pointer is a wild value because the free list was concurrently
mutated by an off-thread PersistentRegion::FreeNode() running on the WebRTC
network thread (see README for the full chain). The lost-update interleaving
left a *used* node on the free list; its `owner_` (a live BasicPersistent*)
was reinterpreted as `next_`, walked one more hop, and the resulting pointer
landed inside .rodata, causing the SEGV_ACCERR on write.

This is the precise corruption claimed in the report: unlocked free-list
mutation in PersistentRegion leading to a wild write at the next AllocateNode.