この脆弱性は、私たちがサービスを提供しているクライアントの一つに影響を及ぼしました。このリポジトリは、オリジナル研究への私たちの貢献です。グループのための一元化された出発点であり、このコンポーネントに影響する類似の脆弱性が再び出現した場合に備えて、すでに基盤が整っているようにするためのものです。ここには、バグの背後にある理論、元の研究者による発見を文書化した概要、そしてラボ環境で影響の有無を検証するための実用的なツール一式がまとめられています。
注記：この研究についてもっと共有できればよかったのですが、会社の制約により、これ以上開示することはできません。ここに含まれるすべての内容はレビュー済みであり、私が拘束されるいかなる契約にも違反していません。そのため、このリポジトリは現在の状態でアーカイブされています。
2026年4月1日、Googleは21件の脆弱性に対処するChromeのセキュリティアップデートを公開しました。そのうちの1つであるCVE-2026-5281は、開示時点で既に実環境において活発に悪用されていました。3日後、CISAはこの脆弱性を既知の悪用済み脆弱性（KEV）カタログに追加し、連邦政府機関に対してパッチ適用を義務付ける拘束力のある運用指令を発出しました。その時点で、この脆弱性はすでに私たちにも影響を及ぼしていました。
このリポジトリが存在する理由はただ一つ、次に同じようなことが起きたときに、ゼロから始めるのではなく、拠り所となる出発点を確保するためです。ここには次のものがまとめられています：
脆弱性がなぜ存在するのかを理解したいとき、まずそのシステムが何を目的に作られ、どのような前提で設計されたのかに立ち返ります。
WebGPUは、Graphics Processing Unit（GPU）上でレンダリングや計算などの操作を実行するためのAPIを公開します。WebGPUは、OpenGLやOpenGL ES（Embedded Systems）を公開しようとする試みではありません。Direct3D 12、Metal、Vulkanなどの最新APIのアイデアに基づいて構築された新しいAPIです。
WebGPUは、ブラウザが長年にわたって使用してきた従来のGPU APIであるWebGLに代わる、現代的な後継です。重要な違いは、WebGPUが安全性と明示的なリソース管理を前提にゼロから設計されていることです。すべてのバッファ、テクスチャ、パイプラインのライフサイクルを自分で宣言します。ブラウザは、JavaScriptとGPUハードウェアの間の検証レイヤーとして機能します。
この脆弱性の中心となるオブジェクト（生成順）：``` GPUAdapter ← represents a physical GPU or software fallback └─ GPUDevice ← your logical connection to the adapter; owns everything ├─ GPUBuffer ← a chunk of GPU-accessible memory ├─ GPUShaderModule ← a compiled WGSL shader program ├─ GPUComputePipeline ← a shader wired to a pipeline layout ├─ GPUBindGroup ← binds buffers as inputs to a pipeline ├─ GPUCommandEncoder ← records a sequence of GPU commands └─ GPUQueue ← submits recorded commands to hardware
ここで重要となるルールは、すべてのオブジェクトはGPUDeviceによって所有されているという点です。デバイスが、そのバッファを参照するコマンドをまだ実行中に持っている状態でバッファを破棄することは、仕様上、明示的に禁止されています。Dawnの実装はそれを検出して拒否することになっています。CVE-2026-5281は、そうしなかったケースです。
---
---
---
<div id='whatisdawn'/>
## ***⚙️ Dawnとは？***
- **[Dawn - オープンソースWebGPU実装](https://dawn.googlesource.com/dawn)**
> Dawnは、開発中のWebGPU標準のオープンソースかつクロスプラットフォームな実装です。いくつかの拡張を備えた、WebGPU IDLをミラーリングするネイティブC++ APIを提供します。
DawnはChrome内部のC++ライブラリであり、WebGPUのJavaScript呼び出しをプラットフォームネイティブのGPUコマンドに変換します。WindowsではD3D12、macOSではMetal、LinuxではVulkanをターゲットとしています。ChromeのJavaScriptエンジンとハードウェアドライバの間に位置し、API呼び出しの検証、コマンドのシリアライズ、オブジェクトのライフタイム追跡、JavaScriptへのエラー通知という4つの役割を担っています。
CVE-2026-5281はライフタイム追跡部分に存在します。具体的には、それらを参照するコマンドがまだハードウェアキュー上で実行待機中である間、DawnがGPUバッファオブジェクトをどれだけ長く保持するかという点にあります。```
JavaScript (V8)
│ WebGPU API calls
▼
Dawn (C++) - validates, serializes, tracks lifetimes, reports errors
│
▼
D3D12 (Windows) - Metal (macOS) - Vulkan (Linux)
│
▼
GPU hardware driver
│
▼
Physical GPU - shader cores, VRAM
Use-After-Free を直感的に理解するには、メモリ上のどこに何が存在するのか、明確なメンタルモデルが必要です。``` High addresses ┌────────────────────────────────────┐ │ Kernel space │ The OS and drivers live here. │ │ User-mode code cannot touch it. ├────────────────────────────────────┤ │ Stack │ Function call frames. Fast. │ (grows downward) │ Freed automatically when the │ │ function returns. ├────────────────────────────────────┤ │ Heap │ Dynamic allocations - malloc, new, │ (grows upward) │ smart pointers like Ref. │ │ Freed only when you say so. ├────────────────────────────────────┤ │ BSS / Data / Text │ Globals, constants, compiled code. └────────────────────────────────────┘ Low addresses
Dawn の C++ オブジェクト（GPUBuffer を支える内部オブジェクトなど）は、ヒープ上に存在します。これらは参照カウント方式です。スマートポインタが、オブジェクトへの参照を保持している数のカウントを管理します。そのカウントがゼロになると、デストラクタが実行され、メモリはアロケータに返還されます。
GPUBuffer は、CPU 側と GPU 側の両方に、同時に2つの表現を持ちます。```
CPU side (Dawn, system RAM)
└─ C++ object - metadata, state flags, and a hardware handle
│
│ handle: ID3D12Resource* (D3D12) - MTLBuffer (Metal) - VkBuffer (Vulkan)
▼
GPU side (driver, VRAM)
└─ Actual memory allocation on the graphics card
JavaScriptがbuffer.destroy()を呼び出したときの意図された動作は、オブジェクトを破棄済みとしてマークし、参照カウントを減らし、ハードウェアハンドルを解放して、VRAMを解放することです。CVE-2026-5281のバグにより、GPUコマンドキューがそのハードウェアハンドルへの参照を保持している間にVRAMが解放され、GPUがもはや自分に属さないメモリに対してアクティブに読み取りまたは書き込みを行っていることになります。
CWE-416: Use After Free (MITRE)
解放されたメモリを参照すると、プログラムのクラッシュ、予期しない値の使用、またはコードの実行を引き起こす可能性があります。以前に解放されたメモリの使用は、有効なデータの破壊から任意のコードの実行まで、さまざまな悪影響を及ぼす可能性があります。
Use-After-Freeは、固定された3ステップのパターンに従い、ブラウザセキュリティにおいて最も一貫して悪用されるメモリ安全性バグのクラスの1つです：```
ステップ2の後、アロケータはその同じメモリ領域を完全に別の割り当てに渡すことができます。攻撃者が解放された領域に何が配置されるかを制御できる場合（ヒープグルーミングと呼ばれる技術）、失効したポインタが読み戻す内容を制御できます。これが、メモリ安全性のバグがコード実行に変わる仕組みです。
GPU側のUAFはCPU側のUAFよりも観測が困難です。その理由は次のとおりです。
- 「アロケータ」はシステムのmallocではなく、GPUドライバのVRAMアロケータです。
- 「失効したポインタ」は、コマンドキューによってまだ参照されているハードウェアハンドルです。
- GPUはコマンドを非同期に実行するため、クラッシュが発生するずっと前にCPUは次の処理に進んでいます。
---
---
---
<div id='thevulnerability'/>
## ***🕳️ 脆弱性***
---
<div id='thevulnerability-whatweknow'/>
### ***📋 公開情報からわかっていること***
以下は、公に確認された事実のみに基づいています。