入り口は3つ、出口は `ObfDereferenceObject` 経由の1つだけだ。

それはコードが間違っているという意味ではない。**不変条件が分散している**という意味だ — どの単一の関数も*「このオブジェクトは今まさに生きている」*を所有していない。したがって、正しさは、すべての呼び出し元が、自分が保持している参照がどれであり、それがどのくらいの期間有効であるかについて合意しているかに依存する。分散された不変条件は、レースコンディションが潜む場所である。なぜなら、レースとは単一の関数内で見えるロジックバグではないからだ。それは2つの関数にまたがって保持された前提のバグである。

そこで私が `PWND` に触れるすべての関数に対して問い始めたのは、*「このコードは正しいか？」*ではなく、次の問いだった：

> **このまったく同じ関数本体が、数命令分だけずれて2つのスレッド上で実行された場合、間違っているのはどちらか？**



## 3. 根本原因

この欠陥は、ウィンドウ破棄パスにおける**参照解放とオブジェクト破棄の間の time-of-check / time-of-use（TOCTOU）ギャップ**であり、並行してハンドルを検証するコンシューマに対する適切な同期が欠如している。

その形だけに単純化すると：```c
/* Thread A — teardown */
NtUserDestroyWindow(HWND hwnd)
{
    PWND pWnd = ValidateHwnd(hwnd);
    if (pWnd) {
        ObfDereferenceObject(pWnd);   /* reference released */

        /* <-- race window: object may become reclaimable here */

        FreeWindowObject(pWnd);       /* teardown proceeds on a pointer
                                         no longer guaranteed live      */
    }
}

if (pWnd->fnid == FNID_BUTTON)    /* use-after-free */
    ...

これが問題になるには2つの条件が真でなければならず、その両方が成立していた:

**(a) その時間窓は本物である。** `ValidateHwnd` はハンドルベースのアクセスを安全にするためのゲートである。既に破棄が始まっているオブジェクトに対して検証が成功し得るのなら、そのゲートはゲートではなく、単なる提案に過ぎない。

**(b) 解放されたメモリは攻撃者が影響を与えられる。** 検証直後に読み取られるフィールドには、メッセージディスパッチを駆動する `fnid` が含まれる。再利用されたメモリから下されたディスパッチの決定は、*"信頼できないクラッシュ"* と *"セキュリティ境界の侵害"* の違いを生む。この区別こそが、これが安定性バグではなく、EoP 影響を伴う CWE-362 であるすべての理由である。

> 観測された **破壊（corruption）** は use-after-free であり、**原因** は CWE-362、すなわち不適切な同期による共有リソースの並行実行である。この2つは別の命題であり、MSRC が重視するのは後者である。**症状だけでなく原因を報告せよ。**

### win32k の競合状態が構造的に難しく見える理由

他のサブシステムでバグを競わせた経験があるなら、win32k は苛立たしいだろう。なぜなら、アーキテクチャが3つの具体的な方法で敵対してくるからだ。

**ウィンドウにはスレッド親和性がある。** ウィンドウは、それを生成したスレッドに属する。サブシステムの多くは、所有スレッドがオブジェクトに触れるという前提の上に構築されている。つまり、素朴に「2つのスレッドを回して同じ API を呼ぶ」というアプローチは、しばしば何も重なり合わない——競合しているのではなく、キューイングしているのだ。2つのパスを同じオブジェクト上で本当に衝突させるには、どの操作が呼び出し元スレッドで実際に実行され、どの操作が所有者側にマーシャリングされるのかを理解する必要がある。

**メッセージディスパッチは部分的に直列化される。** Send と Post は動作が異なり、クロススレッドと同一スレッドのディスパッチもまた異なる動作をする。並行処理の機会に見えるものの一部は、関心のあるコードに到達する前に、静かに順序付けられた操作に変換される。自分のトリガーがどのカテゴリに該当するかを知らなければ、本当の競合状態は到達不能だと結論してしまう——これは「ここにバグはない」と見分けがつかない偽陰性である。

**クリティカルセクションは呼び出し元側に隠れている。** サブシステムの多くは、注視している関数よりずっと上位で取得される粗いロックの下で実行される。これは win32k 監査における最大の時間の無駄の源泉である。可視的な同期がなくても、そこへのすべての経路が既に直列化されているため完全に安全な関数、というものが存在するのだ。**ロックの適用範囲は手続き間の性質である。** 関数を読むだけでなく、コールグラフを遡って調べなければならない。

この3点目こそ、*"この関数にはロックがない"* というシグナルがほぼ無価値である理由であり、今回の探索作業のほとんどが欠陥そのものではなく到達可能性に費やされた理由である。

## 4. 影響度評価がこの値になる理由

MSRC はこれを **重要（Important）、特権昇格（Elevation of Privilege）、CVSS 8.8、攻撃ベクトルはローカル、認証済み** と評価した。これを決定づけたのは2つの性質である:

**低整合性レベルからの到達可能性。** Win32k のメッセージ呼び出し面は、SYSTEM よりはるかに低いコンテキストから到達可能である。これこそがサンドボックスエスケープチェーンに関連する理由であり、サンドボックス内で既にコード実行を達成したレンダラープロセスでも、この面には到達できる。カーネルバグの深刻度は、ほぼ専ら *誰が触れることができるか* の関数であり、破壊がどれほど巧妙かではない。

**ディスパッチに影響を与える破壊。** `switch` が実行対象とするフィールドを破壊することは、ログに記録されるだけのフィールドを破壊することよりも質的に悪い。前者はメモリバグを制御フローの問題に変える。

ここで1つ正確に述べておきたい。なぜなら、初めての CVE を報告する投稿がこれを誇張するのを見たことがあるからだ: **私は競合状態と use-after-free を実証した。兵器化された SYSTEM レベルのエクスプロイトを納品したわけではない。** サンドボックスエスケープという枠組みは、このバグタイプが属する *チェーンのクラス* と、その面が価値を持つ理由を説明するものであり、到達可能性についての議論であって、私がエクスプロイトを構築したという主張ではない。影響度の誇張はベンダーとの信頼を失う最短経路であり、重要なのは私の評価ではなく MSRC の評価である。

## 5. 反証が先——ほとんどの候補は脱落した

誰も書かない部分: これは最初の候補ではなかった。生き残った唯一の候補だったのだ。

私の作業規則は、**候補は有罪が証明されるまで有罪とみなす** というものだ。有望なパターンにはすべて、*悪用できるはずがない* 具体的な理由を書き留め、トリガーを試す前にその理由を確立しに行く。今回の候補より前に私が切り捨てた候補には以下があった:

- 同期がないように見えたが、1フレーム上のロックによって直列化されていたパス、
- 「解放された」オブジェクトが実際には解放ではなくキャッシュされていたパス、
- 実際に競合状態ではあるが、低権限ユーザーが駆動できる呼び出し元からは到達不能なパス。

そのすべては、私が MSRC *に送らなかった* 発見である。そこが要点だ。研究者のスループットとは、生成する候補の数ではなく、誤った候補をどれだけ速く殺せるか——午前2時までそれらを抱え続けなくて済むか——である。

**ほとんどの候補を殺した3つの質問:**

1. **自分より上流で誰かがロックを保持しているか?** ローカルではなく手続き間で見る。関数内にロックがないことは何も意味しない。
2. **非特権の呼び出し元が実際に両方の経路に到達できるか?** 異なる権限レベルを必要とする2つのパス間の競合は、競合ではなく思考実験である。
3. **解放されたメモリは、自分が影響を与えられる時間窓の中で再利用可能か?** 実用上、破棄がアトミックに完了するなら、報告する価値のあるバグは存在しない。

## 6. 検証: 静的解析は仮説を与え、デバッガーは真実を与える

`win32kfull.sys` の静的解析は私に仮説を与えた。しかし、バグそのものを与えることは決してなかった。**競合状態は逆コンパイラには見えない。** 欠陥は命令の中にあるのではなく、インターリーブ（交錯）の中にあるからだ。

### 実験環境

| 役割 | 構成 |
| --- | --- |
| ホスト / デバッガー | Windows 11、WinDbg |
| ターゲット | Windows Server 2022、Build 20348.2159 |
| 解析 | Kali Linux + Windows 11 VM |
| デバッグ転送 | VMware シリアル COM、ホスト → ターゲットのカーネルデバッグ |
| 静的解析 | GhidraMCP 経由の Ghidra |
| トリアージ補助 | 逆コンパイル出力に対する AI 支援パス |

実際の作業を行ったのは3つのインストルメンテーション層である。

### スペシャルプールと Driver Verifier

カーネル UAF 調査における単一の最高レバレッジ手順。デフォルトでは、解放されたプールメモリは、同じサイズの次の割り当てによってほぼ即座に再利用される。つまり use-after-free は通常 *フォルトを起こさない*。他人の有効なデータを読み、実行を継続し、数分後に無関係な場所で爆発する。そしてあなたは無実の関数の監査に3日を費やすことになる。

スペシャルプールはそれを変える。各割り当ては、隣接するガードページを持つ専用ページを取得し、解放されたページは再利用される代わりにアクセス不可としてマークされる。その結果、問題の逆参照は、下流ではなく **それを実行する命令の箇所で** フォルトを起こす:```
!verifier 0x1 win32kfull.sys        ; special pool on the target driver
!verifier 0x8 win32kfull.sys        ; pool tracking

もっともらしいタグとガベージ内容を持つ*割り当て済み*ブロックは、**破損**を示しています。*解放済み*のブロック、または特殊プールのアクセス不可ページ上にあるブロックは、**ライフタイムバグ**を示しています — オブジェクトの消滅後もポインタを保持していた何かがあるということです。これが*"攻撃者がここに書き込んだ"*と*"このオブジェクトは到達可能であるべきではなかった"*の違いであり、ヒープ破損レポートとCWE-362レポートの違いです。

どちらに断定する前に、オブジェクトの種類を照合してください。`PWND`には見分けられる形状があります。フォールトしたメモリにその残骸がまだ残っているなら、ランダムな上書きではなく、ほぼ間違いなくウィンドウ・ライフタイム問題です。

### インタリーブのライブカーネルデバッグ

特殊プールを使用しても、レースはスケジューリングの問題であり、**デバッガはスケジューリングを変えてしまいます。** これがレース作業の中心的な悩みです。計測器が測定対象を乱してしまうのです。破棄パス上のブレークポイントは、オーバーラップさせようとしている正確に2つのスレッドを直列化し、バグは綺麗に消えてしまいます。

これを回避するには、ブレークポイントでレースを捉えようとするのをやめ、代わりに次のようにします。

- **人為的にウィンドウを広げる** — 参照解放と破棄の間の間隔を長くするものは何でも、通常のスケジューリングレートで衝突を到達可能にします。
- **精度を上げるのではなく衝突試行回数を増やす** — 2つのパスを継続的に実行し、確率に任せます。
- **条件付きブレークポイントとワンショットブレークポイントを使用する** — 対象となる状態が存在して初めて有効になり、すべてのエントリで停止するのではありません。
- **フォールト後に、スレッド状態とスタックからインタリーブを確認する** — ライブで観察しようとするのではなく。

フォールト自体は、いったん捉えてしまえば、地味なものです。オブジェクトが別のスレッドで既に破棄を経たメッセージディスパッチパス上の`PWND`の逆参照であり、`!pool`がそのブロックが上書きではなく解放されたことを確認します:```
kd> !analyze -v

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Access violation
FAULTING_MODULE: win32kfull