CVE 항목 및 diff 블록을 포함한 섹션을 스타일 가이드에 맞춰 한국어로 재작성하겠습니다.
[JSC] Keep JSWebAssemblyMemory alive from wasm-originated JSArrayBuffers
CVE: CVE-2026-43716 · Safari 26.5.2 · 2026년 6월 29일 릴리스 영향: 악의적으로 조작된 웹 콘텐츠를 처리하는 과정에서 Safari가 예기치 않게 crash할 수 있습니다. Apple 설명: 메모리 처리 방식을 개선하여 문제를 해결했습니다. Credit: Maher Azzouzi, Tuan and Duc from Calif.io, OpenAI Codex Security - Amy Burnett, Evan Lambert
High. Weak back-pointer 하나가 mode selector 역할까지 겸하고 있었습니다. 그 결과 한 객체가 garbage-collect되는 순간 resize 요청이 조용히 엉뚱한 allocator로 흘러가게 되는데, 이 allocator는 지금 내주려는 페이지를 애초에 예약해둔 적이 없습니다. Script가 collection 시점을 직접 제어할 수 있는 만큼, 이번에 추가된 regression test 자체가 곧 trigger입니다.
Resizable ArrayBuffer는 하나의 JavaScript API를 공유하지만 내부 구현은 두 갈래로 완전히 다릅니다. JS 쪽에서 생성한 버퍼는 생성 시점에 maxByteLength 전체만큼 address space를 예약해두고, 이미 소유한 tail 영역의 보호를 해제하는 방식으로 성장합니다. 반면 WebAssembly.Memory.prototype.toResizableBuffer()로 script에 전달되는 wasm 쪽 버퍼는 wasm linear memory를 들여다보는 창일 뿐이고, 성장 로직 자체는 wasm allocator가 담당합니다. 이 둘을 구분하려면 버퍼가 자신이 어느 쪽 세계에서 왔는지 알고 있어야 하는데, 이번 commit 이전에는 그 정보가 garbage collector가 자유롭게 무효화할 수 있는 pointer 하나에 담겨 있었습니다.
관전 포인트: 페이지가 자신의 WebAssembly.Memory 객체를 버리면서도 여기서 얻은 buffer는 그대로 보유한 뒤, collection을 강제로 발생시키고 그 buffer를 잘못된 allocator를 통해 성장시킬 수 있습니다. 결과적으로 실제로는 한 번도 매핑된 적 없는 메모리 영역에 대해 script에서 관찰 가능한 length가 만들어집니다.
Source/JavaScriptCore/runtime/ArrayBuffer.cpp
Source/JavaScriptCore/runtime/ArrayBuffer.h
Source/JavaScriptCore/runtime/JSArrayBuffer.cpp
Source/JavaScriptCore/runtime/JSArrayBuffer.h
Source/JavaScriptCore/runtime/JSArrayBufferPrototype.cpp
Source/JavaScriptCore/wasm/js/JSWebAssemblyMemory.cpp
Source/JavaScriptCore/wasm/WasmMemory.h
Before: After: JSWebAssemblyMemory ──Ref──► Wasm::Memory JSWebAssemblyMemory ──Ref──► Wasm::Memory │ (GC cell) ▲ │ (GC cell) ▲ │ ┊ WeakPtr │ │ ▼ ┊ ▼ │ WriteBarrier JSArrayBuffer ──raw──► ArrayBuffer┘ JSArrayBuffer ───────┘ (GC-traced) └──raw──► ArrayBuffer
이제 이 edge는 cell에서 cell로 이어지므로, tracing collector가 이를 인식할 수 있습니다. 예전에 native `ArrayBuffer`에 매달려 있다가 끊어지곤 했던 화살표는 완전히 사라졌습니다.
이어서 두 연결 지점의 배선도 함께 바뀝니다. `JSWebAssemblyMemory::associateArrayBuffer`는 더 이상 wrapper 생성 전에 `m_buffer->setAssociatedWasmMemory(m_memory.ptr())`를 호출하지 않습니다. 대신 `JSArrayBuffer`를 먼저 생성한 뒤, buffer가 resizable하면서 non-shared인 경우에 한해 `arrayBuffer->setAssociatedWasmMemoryWrapper(vm, this)`를 호출합니다. `disassociateArrayBuffer` 역시 이미 `m_bufferWrapper`에 추적 중인 wrapper를 통해 연결을 해제한 뒤 이를 버립니다.
ownership이 보장됨에 따라 wasm growth semantics도 한 계층 위로 옮겨갑니다. `JSArrayBufferPrototype.cpp`의 `arrayBufferProtoFuncResize`는 이제 가장 먼저 `associatedWasmMemoryWrapper()`를 확인하고, 값이 설정되어 있으면 wasm 분기를 그 자리에서 직접 처리합니다. shrink 요청은 `"Cannot shrink WebAssembly memory"`로 거부하고, `PageCount::pageSize`의 배수가 아닌 길이는 `RangeError`로 거부하며, 그 외의 경우 `jsMemory->memory().grow(vm, PageCount::fromBytes(delta))`를 호출합니다. 같은 로직은 `ArrayBuffer::resize()`에서 제거되는데, page-multiple/shrink 검증과 weak-upgrade delegation 블록이 모두 삭제되고, 함수 앞부분에는 `RELEASE_ASSERT(!isWasmMemory())`가 추가되어 있습니다. `HostResizeArrayBuffer`에 대한 스펙 주석도 이 로직과 함께 이동합니다.
후속 정리도 이어집니다. `Wasm::Memory`는 더 이상 weak-pointer 지원이 필요 없어져 `RefCountedAndCanMakeWeakPtr<Memory>`에서 평범한 `RefCounted<Memory>`로 되돌아가고, `ThreadSafeWeakPtr` include도 제거됩니다. debug tripwire였던 `checkLifetime()` — `ASSERT(!refCountDebugger().deletionHasBegun())` — 도 `adopt()`와 `growSuccessCallback()`의 호출 지점과 함께 삭제됩니다. commit message에는 `ArrayBuffer.prototype.resize` 실행 동안 `WebAssembly.Memory`를 pin해 두었던 이전 spot fix(`305413.660@safari-7624-branch`)가 이번 commit으로 되돌려졌다는 내용도 함께 기록되어 있습니다.
마지막으로 `JSTests/wasm/stress/wasm-resizable-buffer-resize-after-gc.js`가 이번 회귀 테스트입니다. IIFE 안에서 memory를 생성하고 그 resizable buffer만 꺼낸 뒤 memory 참조를 버리고, 재귀 helper로 낡은 stack root를 지우고, full GC를 두 번 강제로 수행한 다음, 살아남은 buffer를 resize하고 값을 기록하는 과정을 다섯 번 반복합니다.
**Background**
**Resizable ArrayBuffers.** resizable `ArrayBuffer`는 `maxByteLength` 옵션과 함께 생성되는 `ArrayBuffer`입니다. `ArrayBuffer.prototype.resize(n)`은 길이를 제자리에서 바꾸며, 이 위의 typed-array view는 detach되지 않고 현재 길이를 그대로 추적합니다. JSC 내부에서는 `m_hasMaxByteLength`가 설정된 `ArrayBufferContents`가 이 상태를 담당하고, mapping을 서술하는 `RefPtr<BufferMemoryHandle> m_memoryHandle`이 함께 존재합니다.
**The up-front reservation model.** JS에서 생성된 resizable buffer의 경우, `ArrayBuffer.cpp`의 `tryAllocateResizableMemory()`가 `BufferMemoryManager::tryAllocateGrowableBoundsCheckingMemory()`를 통해 `maxByteLength` 전체에 해당하는 virtual address space를 미리 예약합니다. 이 중 초기 바이트만 commit하고, 나머지는 `OSAllocator::protect()`로 접근 불가 상태로 표시합니다. 따라서 growth는 저렴하고 로컬한 작업이 됩니다. 이미 프로세스가 소유한 tail 영역의 일부를 unprotect하는 것뿐입니다. 주소 공간이 생성 시점에 이미 확보되어 있으므로, 이 경로는 allocator와 별도로 협상할 일이 없습니다.
**Wasm memory modes.** `Wasm::Memory`는 *signaling* 방식이거나 *bounds-checking* 방식 중 하나입니다. Signaling은 큰 virtual reservation을 잡아두고 범위를 벗어난 접근을 hardware trap으로 잡아내는 방식이고, bounds-checking은 모든 접근에 명시적인 길이 비교를 동반하는 방식입니다. commit message는 여기서 중요한 결과를 하나 짚습니다. JS에서 생성된 resizable buffer는 max를 미리 예약하지만, wasm에서 생성된 buffer는 bounds-checking 방식이면 그렇게 하지 않고, signaling 방식이면 그렇게 한다는 점입니다.
**`toResizableBuffer()`와 소유권 구조.** `WebAssembly.Memory.prototype.toResizableBuffer()`는 wasm memory의 linear memory를 가리키는 `ArrayBuffer` view를 script에 전달합니다. `JSWebAssemblyMemory::associateArrayBuffer`가 native `ArrayBuffer`를 생성하고 `makeWasmMemory()`로 태그를 붙인 뒤 `JSArrayBuffer` cell로 감쌉니다. native `Wasm::Memory`에 대한 유일한 strong reference는 `JSWebAssemblyMemory::m_memory`가 `Ref` 형태로 갖고 있으며, `adopt()`는 이를 가져온 직후 `m_memory->refCount() == 1`을 확인합니다. 즉 native memory 객체의 lifetime은 오직 이 GC cell 하나에만 묶여 있습니다.
**`WeakPtr` versus `Ref`.** `WeakPtr<T>`는 대상을 살려두지 않습니다. 대상이 파괴되고 나면 `.get()`은 null을 반환합니다. 반면 `Ref`와 `RefPtr`은 대상을 살려두는 owning reference입니다.
**`WriteBarrier<T>` and `visitChildren`.** `WriteBarrier<T>`는 한 cell에서 다른 cell로 이어지는 GC-traced pointer를 위한 JSC의 필드 타입입니다. 이 edge를 통해 대상을 살려두려면, 소유 클래스가 marking 과정에서 이를 보고해야 합니다. 클래스에 `DECLARE_VISIT_CHILDREN`을 선언하고 `visitChildrenImpl` 안에서 `visitor.append(...)`를 호출하는 방식입니다. cell 사이의 reference cycle은 여기서 문제가 되지 않습니다. tracing collector는 도달 불가능한 cycle을 통째로 회수하기 때문이며, 그래서 commit message는 이번 구조를 의도된 "GC lifetime cycle"로 표현할 수 있는 것입니다.
**`PageCount`.** JSC의 wasm page 추상화입니다. `PageCount::pageSize`는 65536바이트이며, `PageCount::fromBytes()`는 바이트 단위 delta를 page 단위로 변환합니다.
<!-- GATE:analysis -->
**Analysis**
이 버그는 ownership 오류이며, 그 결과는 dangling read가 아니라 *구현이 조용히 바뀌는* 형태로 나타납니다. null이 될 수 있는 non-owning pointer가 분기 선택자로 쓰이고 있었고, 그 pointer가 null일 때 떨어지는 분기는 전혀 다른 allocator에 속한 코드였습니다.
script GC ArrayBuffer::resize()
──────── ── ─────────────────────
m = new WA.Memory()
buf = m.toResizableBuffer()
└─ ArrayBuffer.m_associatedWasmMemory = WeakPtr(Wasm::Memory)
drop m ────────────────► JSWebAssemblyMemory unreachable
~Ref
위 그림의 각 단계를 순서대로 따라가 보겠습니다. weak edge는 `associateArrayBuffer`가 `toResizableBuffer()` 시점에 설치하며, native `ArrayBuffer`에서 native `Wasm::Memory`를 가리킵니다. 이후 script는 buffer는 유지한 채 `WebAssembly.Memory` 객체에 대한 마지막 참조를 버립니다. buffer 자체가 독립적인 API를 가진 first-class 값인 만큼, 이는 지극히 평범한 동작입니다. 그러면 `JSWebAssemblyMemory` cell이 garbage가 되고 그 안의 `Ref<Wasm::Memory>`가 destruct되면서, buffer가 들고 있던 weak pointer는 null이 됩니다. 이 commit 이전에는 그 cell을 buffer 대신 살려둘 traced edge가 object graph 어디에도 없었습니다.
여기서 빠져 있던 invariant는 명확합니다. *어떤 객체가 협력 객체에 작업을 위임한다면, 그 작업이 도달 가능한 동안에는 협력 객체를 살려두는 참조를 스스로 소유해야 한다*는 원칙입니다. `buf.resize()`는 영원히 도달 가능한 채로 남지만, 협력 객체인 `Wasm::Memory`는 그렇지 못했습니다.
이제 세 번째 단계로 넘어가 보겠습니다. `ArrayBuffer::resize()`는 `ArrayBuffer.prototype.resize`의 유일한 진입점이었고, 그 안의 wasm 처리 로직이 바로 diff에서 삭제되는 upgrade-and-delegate 블록입니다.
```cpp
RefPtr<Wasm::Memory> memory = m_associatedWasmMemory.get();
if (memory) {
std::ignore = memory->grow(vm, PageCount(newPageCount.pageCount() - oldPageCount.pageCount()));
return deltaByteLength;
}
size_t desiredSize = newPageCount.bytes(); // ← fallthrough on null
else가 없습니다. 에러를 반환하는 코드도 없습니다. upgrade가 null이 되면 코드는 그대로 desiredSize와 범용 resizable-buffer growth 코드로 흘러 들어갑니다. 이 코드는 원래 tryAllocateResizableMemory()가 생성한 buffer를 위한 것으로, 생성 시점에 tryAllocateGrowableBoundsCheckingMemory()가 maxByteLength 전체 mapping을 예약해 둔 상태를 전제로 하며, growth란 이미 소유하고 있는 tail 영역을 unprotect하는 작업일 뿐입니다. commit message에 따르면, wasm에서 생성된 bounds-checking memory는 애초에 그런 예약을 한 적이 없습니다.
요란한 실패보다 더 나쁜 지점은, 살아남은 상태가 겉보기에 멀쩡해 보인다는 데 있습니다. RefPtr<BufferMemoryHandle> m_contents.m_memoryHandle은 Wasm::Memory보다 오래 살아남아 여전히 maximum()을 100 page로 보고합니다. 그래서 growth 경로를 지키는 sanity check도 —
ASSERT(memoryHandle->maximum() >= newPageCount);
— 그대로 통과합니다. 선언된 maximum 값이 그 뒤의 page들이 실제로 mapping되어 있다는 근거로 읽히고 있는 셈인데, wasm allocator의 bounds-checking 모드에서는 그렇지 않습니다. 이후 범용 경로는 m_contents.m_sizeInBytes를, 그리고 이와 함께 buffer의 byteLength를, wasm allocator가 한 번도 mapping한 적 없는 영역까지 밀어 올립니다. 이 buffer 위에 생성되는 모든 Uint8Array는 이렇게 부풀려진 길이를 그대로 물려받습니다. 삭제된 검증 블록은 이 도달 가능한 구조를 한층 더 악화시켰습니다. page-multiple 검사와 shrink 검사 자체가 Options::useWasmMemoryToBufferAPIs()에 의해 gating되어 있었고, 이제는 자신이 wasm buffer를 다루고 있는지조차 알 수 없게 된 바로 그 함수 안에 놓여 있었기 때문입니다.
실제 trigger는 추가된 회귀 테스트 그대로이며, 특별히 이례적인 조건이 필요하지 않습니다.
- IIFE 안에서
new WebAssembly.Memory({ initial: 1, maximum: 100 })를 생성합니다. m.toResizableBuffer()를 바깥 scope의buf에 담아두고, IIFE가 반환되도록 하여m이 더 이상 참조되지 않게 합니다.- 재귀 helper인
flushStackRoots(64)를 호출해, 그렇지 않으면 memory를 붙잡아 둘 낡은 conservative stack root를 덮어씁니다. fullGC()를 두 번 호출하고 그 사이에 root flush를 한 번 더 넣어, collection이 운에 맡겨지지 않고 항상 동일하게 일어나도록 만듭니다.buf.resize(65536 * 100)을 호출한 뒤, 새로 만든Uint8Array(buf)를 통해 읽고 쓰며view[view.length - 1] = 0x42까지 수행합니다.
이 단계들은 모두 평범한 웹 콘텐츠 수준에서 가능한 동작입니다. 여기서 GC 타이밍은 이겨야 하는 race가 아니라 도달해야 하는 하나의 상태이며, 테스트가 fullGC()를 두 번 사용하는 구조는 script에서 이 상태에 얼마나 기계적으로 도달할 수 있는지를 보여줍니다.
fix는 이 invariant를 방어적으로가 아니라 구조적으로 복구합니다. buffer의 wrapper cell은 이제 WriteBarrier<JSWebAssemblyMemory> m_associatedWasmMemoryWrapper를 갖고 이를 visitChildrenImpl에서 보고하므로, script가 buffer를 참조할 수 있는 한 collector는 이 edge를 통해 JSWebAssemblyMemory를 marking하고, 그것이 소유한 Ref<Wasm::Memory>는 destruct될 수 없습니다. 두 cell 사이의 연결은 이제 진짜 cycle이 되고, tracing collector는 별다른 도움 없이도 이를 처리합니다. buffer가 살아 있는 동안에는 이 edge가 더 이상 null이 될 수 없으므로, 분기를 상위 계층으로 끌어올리는 작업도 안전해집니다. arrayBufferProtoFuncResize는 associatedWasmMemoryWrapper()를 먼저 확인하고, 값이 있으면 shrink 거부와 page-multiple 거부를 직접 처리한 뒤 jsMemory->memory().grow()를 호출하며, ArrayBuffer::resize에는 아예 진입하지 않습니다. 버그를 일으켰던 fallthrough는 단순히 발생 가능성을 낮춘 수준이 아니라, ArrayBuffer::resize 맨 앞의 RELEASE_ASSERT(!isWasmMemory())로 아예 도달 불가능하다고 못박아 둡니다. 이로써 wasm buffer가 범용 growth 코드에 도달하는 남은 경로가 있더라도, 즉시 abort로 이어져 exploit할 수 없는 상태가 됩니다.
이번 commit이 삭제한 부분에서 두 번째 측면도 드러납니다. 이전에 배포되었던 spot fix(305413.660@safari-7624-branch)는 ArrayBuffer.prototype.resize가 실행되는 동안에만 WebAssembly.Memory를 pin해 살려두었고, Wasm::Memory::checkLifetime()은 !refCountDebugger().deletionHasBegun()을 확인하는 debug tripwire로 존재했습니다. 이 assertion은 destruction이 이미 시작된 Wasm::Memory를 누군가 사용하고 있을 때에만 의미를 갖습니다. 이 두 장치는 모두 같은 문제, 즉 weak upgrade가 유일한 소유자의 destruction과 race하는 상황을 겨냥하고 있었습니다. 이 측면이 실제로 발현되면 길이 불일치가 아니라 grow() 내부에서 refcounted native 객체에 대한 use-after-free로 나타났을 것입니다. 두 장치 모두 이번 패치가 제거한 하나의 weak edge 위에 서 있었기 때문에, spot fix와 tripwire 둘 다 이 edge와 함께 삭제될 수 있었습니다.
영향 범위는 WebContent process, 즉 JSC heap과 wasm linear memory 안으로 한정됩니다. Apple의 advisory는 이 결과를 예기치 못한 Safari crash로 설명하고 있습니다. 이 구조가 시사하는 primitive는 script에서 도달 가능한 ArrayBuffer의 길이와 backing store 사이의 불일치이며, Uint8Array view를 통한 상대적인 out-of-bounds read/write로 이어집니다. 오프셋의 범위는 memory에 선언된 maximum 값에 묶여 있으므로 사실상 공격자가 상당 부분 결정할 수 있습니다. 이를 renderer 바깥으로 확장하려면 별도의 sandbox escape가 여전히 필요합니다.
mode selector로 쓰이던 weak back-pointer가 null이 되자, wasm 기반 buffer가 범용 allocator를 통해 조용히 자라났습니다. 이 allocator는 "max가 이미 예약되어 있다"는 전제를 충족한 적이 없었습니다.
Insight
이전 이력 자체가 교훈을 남깁니다. 앞선 fix는 resize 본문이 실행되는 동안 WebAssembly.Memory를 pin했고, checkLifetime()은 destruction 도중인 memory를 아무도 건드리지 않는다는 것을 확인했습니다. 둘 다 같은 edge를 겨냥해 window를 좁히거나 tripwire를 심은 조치였을 뿐, 협력 객체가 애초에 사라질 수 있었던 representation 자체는 바꾸지 못했습니다. commit message의 서술에서 진짜 결함이 representation에 있었다는 단서가 드러납니다. weak edge를 유지한다는 것은 "non-wasm ArrayBuffer 코드가 WebAssembly.Memory가 collect될 가능성을 항상 염두에 두어야 한다"는 뜻이었고, 이는 그 파일을 앞으로 수정할 때마다 collect된 협력 객체를 고려해야 하는 부담으로 남습니다. 연결을 strong reference로 바꾸고 fallback 경로를 도달 불가능하다고 못박음으로써, 이 부담과 버그 유형을 한꺼번에 해소한 셈입니다. 범위를 좁힌 protector 방식이었다면 둘 중 어느 쪽도 해결하지 못했을 것입니다.
Audit directions
-
Nullable non-owning references used as branch selectors. Narrow:
Source/JavaScriptCore/runtime와Source/JavaScriptCore/wasm에서.get()결과가else없이 code path를 분기시키는WeakPtr</Weak<멤버를 grep으로 찾아볼 필요가 있습니다. 시작점으로는ArrayBuffer::m_wrapper(Weak<JSArrayBuffer>)와JSWebAssemblyInstance,BufferMemoryHandle사용처의Weak/WeakPtr필드가 적합합니다. Wider: 같은 패턴은 dispatch에 사용되는 모든 nullable indirection에서 나타날 수 있습니다. Caller가 null을 마주칠 수 있는RefPtr멤버,std::optionalcollaborator,dynamicDowncast<>결과, teardown 시 clear되는 캐시된 raw pointer 등이 해당됩니다. 찾아야 할 형태는 true-branch가 특수화된 구현으로 위임하고, false-branch는 error return이 아니라 일반 코드로 그대로 fallthrough되는 조건문입니다. Widest: 여기서 재사용 가능한 invariant는 caller의 잘못 없이도 null이 될 수 있는 reference는 behavior를 선택하는 데 쓰여서는 안 되며, 오직 성공과 명시적 실패를 가르는 gate 역할만 해야 한다는 점입니다. 이는 Chromium의base::WeakPtr, Rust의Weak::upgrade(), Java의WeakReference, JS의WeakRef에도 그대로 적용됩니다. 모든 단계에서 던져야 할 질문은 동일합니다. upgrade가 아무것도 반환하지 않을 때, 코드가 명확히 실패하는지 아니면 조용히 다른 동작으로 넘어가는지입니다. -
One API surface over two allocators with different contracts. Narrow:
ArrayBuffer::resize가 이제!isWasmMemory()를 hard-assert하게 되었으므로, wasm-marked buffer에 대해 size를 변경하거나 content를 넘겨주는 나머지ArrayBuffer연산들도 점검해야 합니다.ArrayBuffer::grow,transfer/transferToFixedLength,detach,refreshAfterWasmMemoryGrow,SharedArrayBufferContents::grow가 대상이며, 각각이 reservation에 의존하는 로직을 적용하기 전에isWasmMemory()나 새로 추가된JSArrayBuffer::associatedWasmMemoryWrapper()를 확인하는지 살펴봐야 합니다. Wider: 같은 형태는 container가 여러 allocator를 추상화하는 곳이면 어디서든 반복됩니다.BufferMemoryHandle의 bounds-checking 사용처와 signaling 사용처를 구분해서 점검하고,memoryHandle->maximum()을 그 뒤 페이지들이 reserve되어 있다는 근거로 취급하는 consumer가 있는지도 확인해야 합니다. 단서는 size/capacity accessor가 in-place mapping 변경을 승인하는 용도로 쓰이고 있다는 점입니다. Widest: capacity 필드는 의도를 기록할 뿐, reservation을 증명하지 않습니다. max/capacity query를 메모리가 실제로 mapping되어 있다는 증거로 대체해서는 안 됩니다. 이는 이중 전략을 쓰는 모든 allocator에 적용됩니다. jemalloc과 mmap을 병행하는 path, Rust의Vec::with_capacity와 mmap 기반 arena, Java의 directByteBuffer와 heapByteBuffer모두 마찬가지입니다. -
Newly introduced GC edges must be complete and symmetric. Narrow:
JSArrayBuffer::m_associatedWasmMemoryWrapper가JSWebAssemblyMemory::associateArrayBuffer한 곳뿐 아니라, script에 wasm-originated resizable buffer를 넘겨주는 모든 경로에서 설정되는지 확인해야 합니다. Commit message에 언급된SerializedScriptValue.cpp의WebCore::CloneDeserializer::readTerminal을 비롯해, 새 wrapper에 wasm-backed resizable buffer를 만들어낼 수 있는 structured-clone 경로나JSArrayBuffer::create호출부를 추적할 필요가 있습니다. Link 없이 생성된 wrapper는 새로 추가된RELEASE_ASSERT(!isWasmMemory())에 걸려 abort될 수 있습니다. Wider: 이 클래스는 JSC cell에 추가된 모든WriteBarrier<T>필드에 해당합니다. 각 필드가 해당 클래스의visitChildrenImpl에 추가되어 있는지, 그리고 대응되는 teardown 지점(여기서는clearAssociatedWasmMemoryWrapper()를 거치는disassociateArrayBuffer)에서 clear되는지 확인해야 합니다.visitChildrenImpl에서 필드 이름이 전혀 언급되지 않는 클래스의WriteBarrier<선언을 grep으로 찾아보는 방식이 유효합니다. Widest: lifetime 관리를 위해 추가된 ownership edge는 모든 construction site에서 생성되고 모든 teardown site에서 해제되어야 하며, 그렇지 않으면 이 비대칭성은 leak 또는 unowned pointer로 다시 드러납니다. 이는 V8의 handle과Traced<>필드, SpiderMonkey의TraceEdge, Blink Oilpan의Member<T>에도 동일하게 적용됩니다. -
Spot fixes and debug tripwires as audit leads, not closure. Narrow: 이번 commit이 다른 곳에서는 제거한 관용구가 JSC와 WebCore에 남아 있는지 grep으로 찾아볼 필요가 있습니다.
refCountDebugger().deletionHasBegun()assertion, 하나의 call 동안 collaborator를 살려두기 위해서만 도입된 임시Ref/RefPtrlocal(보통 그 사실을 명시하는 주석이 붙어 있습니다), wasm과 typed-array 코드의protector스타일 local이 대상입니다. 각각에 대해 그 밑바탕의 edge가 애초에 weak하게 설계되어 있는지 물어봐야 합니다. Wider:// keep alive for the duration of같은 주석이 붙은 scope-local protector가WeakPtr, raw pointer,ThreadSafeWeakPtr타입의 멤버와 짝을 이루는 경우가 모두 이 패턴에 해당합니다. 형태는 protector의 lifetime이 함수 하나에 국한되어 있는데, 그 protector가 보호하는 association은 그 함수보다 더 오래 살아남는다는 것입니다. Widest: lifetime을 call site 하나로 좁히는 것은 window를 줄일 뿐, collaborator가 아예 사라질 수 있다는 representation 자체의 문제를 고치지는 못합니다. 이는 refcount와 GC를 혼합한 모든 구조에 적용됩니다. Blink의Persistent/Member분리, Objective-C의__weak와 임시 strong local 조합, Rust에서Arc/Weakupgrade를 한 block 안에서만 붙잡고 있는 경우가 모두 해당됩니다. 매칭 단서는 weak 멤버로부터 얻어낸 임시 strong reference가 존재하는데, 같은 멤버가 다른 곳에서는 그 보호 없이 dereference되고 있는 상황입니다.