三种进入方式，一条 `ObfDereferenceObject` 退出路径。

这并不意味着代码是错的。它意味着**不变量是分布式的** —— 没有任何单个函数单独拥有*“此对象当前仍存活”*，因此正确性取决于每个调用方对被持有的引用类型及其有效期限达成一致。分布式不变量正是竞态条件滋生之处，因为竞态从来都不是你可以在单个函数里看到的逻辑缺陷。它是跨越两段代码所持有假设中的缺陷。

于是，我开始对每个接触 `PWND` 的函数问的问题不再是*“这段代码正确吗？”*，而是：

> **如果这段函数体恰好执行在两个相隔几条指令的线程上，哪一个才是错的？**



## 3. 根本原因

该缺陷是窗口销毁路径中**引用释放与对象销毁之间的检查时/使用时（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 */
    ...

要让这一点变得重要，必须满足两件事，而这两件都成立：

**(a) 这个窗口是真实存在的。** `ValidateHwnd` 是理应让基于句柄的访问变得安全的关卡。如果对一个已经开始销毁的对象，校验仍然能够成功，那么这个关卡就不是关卡——它只是一个建议。

**(b) 被释放的内存可以被攻击者影响。** 校验后紧接着读取的字段包括 `fnid`，它驱动消息分发。基于被回收内存做出的分发决策，正是 *“不可靠的崩溃”* 与 *“安全边界被突破”* 之间的差别。这一区别正是它被定性为 CWE-362、具有提权（EoP）影响，而不是稳定性 bug 的全部原因。

> 观察到的**破坏**是释放后使用（use-after-free）；而**根因**是 CWE-362，即以不当同步方式并发使用共享资源。这是两回事，MSRC 在意的是后者。**请报告根因，而不仅仅是表象。**

### 为什么 win32k 竞态在结构上比看起来更难

如果你在其他子系统中挖过竞态 bug，win32k 会令你抓狂，因为它的架构会在三个特定方面与你作对。

**窗口具有线程亲和性。** 窗口属于创建它的线程。该子系统的很多部分都建立在这样一个假设上：拥有窗口的线程才是操作该对象的线程。这意味着那种朴素的“开两个线程调用同一 API”的方法往往不会产生任何重叠——你并不是在制造竞态，而是在排队。要让两条路径真正在同一对象上发生碰撞，你需要弄清楚哪些操作实际在调用方线程上执行，哪些操作会被封送到所有者线程。

**消息分发会部分地串行化你的操作。** Send 和 Post 的行为不同，跨线程与同线程的分发行为又不一样。一些看似存在并发机会的操作，在到达你关心的代码之前，就被悄悄转换成了有序操作。如果你不知道自己的触发器属于哪一类，你就会得出“真正的竞态不可达”的结论——这是一个与“这里没有 bug”看起来一模一样的假阴性。

**临界区藏在调用方里。** 该子系统的许多代码都在一个粗粒度锁下运行，而这个锁是在你盯着看的函数之上很远的地方获取的。这是在 win32k 审计中浪费时间最大的一个来源：一个函数没有任何可见的同步机制，却依然完全安全，因为进入它的每一条路径都已被串行化。**锁覆盖是一种跨过程（interprocedural）属性。** 你必须沿着调用图向上走，而不能只读这个函数。

正是这第三点，使得 *“这个函数里没有锁”* 作为信号几乎毫无价值，也解释了为什么这次狩猎中的大部分工作花在了可达性上，而不是缺陷本身。


## 4. 为什么影响评级会是如此

MSRC 将其评定为 **重要（Important）、权限提升（Elevation of Privilege）、CVSS 8.8、攻击向量为本地、需要认证（authenticated）。** 决定这一评级的有两个属性：

**从低完整性级别可达。** Win32k 消息调用面可以从远低于 SYSTEM 的上下文中触达。这正是它与沙箱逃逸链相关的原因——一个已经在其沙箱内实现代码执行的渲染进程，仍然可以触达这一表面。内核 bug 的严重性主要取决于 *谁能够触达它*，而不是破坏手法有多巧妙。

**影响分发的破坏。** 破坏 `switch` 所依赖的字段，在性质上比破坏一个仅被记录的字段更严重。前者把内存 bug 变成了控制流问题。

我想在这里把一件事说准确，因为我见过首次 CVE 作者过度夸大这一点：**我演示了竞态和释放后使用，但我并没有交付一个武器化的 SYSTEM 级利用。** 沙箱逃逸的表述描述了这类 bug 所属的 *链类别*，以及为什么这一表面有价值——这是关于可达性的论证，而不是声称我构建了一个这样的利用。过度夸大影响是消耗厂商信任的最快方式，而 MSRC 的评定才是真正重要的数字，而不是我的说法。



## 5. 证伪在先——大多数候选都被淘汰了

没人写到的部分：这并非第一个候选，而是活下来的那一个。

我的工作准则是：**一个候选者直到被证明有罪之前，都被视为有罪。** 每个看似有戏的模式，我都会写下一条具体的理由，说明它 *为什么不应* 被利用，然后我会在尝试触发它之前，先去验证这条理由。在这之前被我关闭的候选包括：

- 看起来没有同步、但实际上被上一层函数获取的锁串行化了的路径，
- 所谓“已释放”对象实际上是被缓存而并未释放的路径，
- 确实存在竞态、但低权限用户无法驱动任何调用方触达的路径。

这些每一条都是我 *没有* 发给 MSRC 的发现。这才是重点。研究者的吞吐量不在于他们生成了多少候选，而在于他们能以多快的速度淘汰错误的候选，这样他们就不会在凌晨 2 点还抱着这些候选不放。

**淘汰大多数候选的三个问题：**

1. **在我之上是否有代码持锁？** 这是跨过程的问题，不是局部问题。函数内没有锁说明不了任何问题。
2. **非特权调用方是否真的能同时触达两边？** 两条需要不同权限级别的路径之间的“竞态”不是竞态，而是思想实验。
3. **被释放的内存是否能在我可影响的时间窗口内被回收利用？** 如果从实际效果上看销毁是原子完成的，那就没有值得报告的 bug。



## 6. 验证：静态分析给出假设，调试器给出真相

对 `win32kfull.sys` 的静态分析给了我假设，但它永远不可能直接给我 bug。**竞态条件在反编译器中是看不到的**，因为缺陷不在指令里，而在于交错执行。

### 实验环境

| 角色 | 配置 |
| --- | --- |
| 主机 / 调试器 | Windows 11, WinDbg |
| 目标机 | Windows Server 2022, Build 20348.2159 |
| 分析环境 | Kali Linux + Windows 11 VM |
| 调试传输 | VMware 串口 COM，主机 → 目标内核调试 |
| 静态分析 | Ghidra via GhidraMCP |
| 分类辅助 | AI 辅助对反编译输出进行一遍梳理 |

真正起作用的是三个插桩层。

### 特殊池（Special Pool）和驱动程序验证器（Driver Verifier）

这是任何内核 UAF 调查中最具杠杆效应的一步。默认情况下，被释放的池内存几乎会立即被下一个大小相似的分配所复用——这意味着释放后使用通常 *不会触发异常*。它会读取别人的有效数据，继续执行，然后在几分钟后的某个毫不相干的地方引爆。然后你就会花三天时间去审计一个无辜的函数。

特殊池改变了这一点。每次分配都会获得自己的页面，旁边还有一个守护页（guard page）；被释放的页面会被标记为不可访问，而不是被回收复用。结果是，肇事的内存解引用会在 **执行它的那条指令处** 触发异常，而不是在后续的下游代码中：```
!verifier 0x1 win32kfull.sys        ; special pool on the target driver
!verifier 0x8 win32kfull.sys        ; pool tracking

一个被*分配*的块，带有看似合理的标签和垃圾内容，指向**损坏**。一个被*释放*的块，或位于特殊池的不可访问页中的块，指向**生命周期 bug**——某些东西在对象死亡后仍握着指向它的指针。这就是*“攻击者在这里写了内容”*与*“这个对象本不该可达”*之间的区别，也是堆损坏报告与CWE-362报告之间的差别。

在确定是哪一种之前，先交叉检查对象类型。`PWND` 具有可辨识的形状；如果你出错的内存仍带有它的残留，那么你几乎可以肯定遇到的是窗口生命周期问题，而不是随机的覆盖写入。

### 在交错上进行实时内核调试

即使有了特殊池，竞态仍然是调度问题，而且**调试器会改变调度。** 这正是竞态工作最令人沮丧之处：工具扰动它所测量的对象。在销毁路径上设置断点恰恰会序列化你试图重叠的那两个线程，于是这个 bug 就会礼貌地消失。

解决之道是停止试图用断点捕捉竞态，而是：

- **人为加宽窗口**——任何延长引用释放与销毁之间间隔的做法，都会让碰撞在正常调度速率下变得可达，
- **增加碰撞尝试次数而不是精度**——持续运行这两条路径，让概率去发挥作用，
- **使用条件断点和一次性断点**，只在感兴趣的状态出现后才启用，而不是每次进入都中断，
- **在故障发生后确认交错**，通过线程状态和堆栈来确认，而不是试图实时观察它。

一旦你得到故障本身，它并不光鲜——在消息分发路径上解引用了一个 `PWND`，而该对象已在另一个线程上完成了销毁，`!pool` 确认该块是被释放而不是被覆盖：```
kd> !analyze -v

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