复核 81fe1107：四条修复里三条的判据有牙，shutdown_ 那两处的 UAF 没有判据 #25

Activity

1. Antruly

   added a commit that references this issue on Sep 21, 2026

   perf(web): 响应头表预留位置；补上 SUPER 块 shutdown 后释放的用例

   ...

   64fbe08
2. Antruly commented on Sep 21, 2026

   

   Antruly

   on Sep 21, 2026

   Owner

   More actions

   谢谢做这套变异复核 —— 逐条对着源码核了一遍，下面按你的四条分别回。

   机制 #1 逐字属实

   release_bytes() 的第一句就是 if (config_.max_total_memory == 0) return;
   （src/expand/uvcpp_memory_pool.cpp:319），而那条用例用的是默认 config。你说的完全对。

   「shutdown_ 那两处没有判据」—— 对，而且比你说到的更彻底

   比「用例看不见」还要空一层：shutdown_ 分支里 SUPER 那半边全仓零覆盖。

   • 旧用例 test_pool_release_cache_after_shutdown 用的是 64 字节 TINY 块，只走非 SUPER 那一支；
   • 而 SUPER 块根本不进线程缓存（thread_local_cache::push() 对 idx >= 7 返回 false，
     块当场交给 push_to_global_pool()），所以它只能由「shutdown() 之后直接 deallocate()
     一个大块」走到 —— 全仓此前没有任何用例走过这条路。

   我按你的建议 (a) 在旧用例的注释里写明了它证的是释放器配对、不是那处 UAF，(b) 没有采纳
   （改用非零 max_total_memory 只是让 release_bytes() 不是空调用，仍然不产生判据，还可能把
   那条用例原本证的东西搅浑）。代替它的是新加一条用例，见下。

   「纯形式 UB」这一点我不同意 —— 在这台机器上是硬崩

   你那边读到「值仍是 96」，我这边也一样；但读数不可观测不等于没有判据，它是分配器相关的。
   MSVC + 全量页堆下它是可观测的，而且很干脆。实测（build-h2，shutdown_ 两处一起还原成
   release_bytes(block->size) 写在 free 之后）：

   装置	读数
   修复后（含新用例）	裸跑 10/10 绿；页面堆绿
   M3 变异体 + 新用例	裸跑 10/10 崩（rc=139）；页面堆抓到 0xC0000005
   M3 变异体、把新用例摘掉	20 次里崩 11 次（约一半）

   cdb 把崩点分别定位到 push_to_global_pool+0x7e（SUPER 支）与 +0x3b（非 SUPER 支），
   调用点分别在 test_memory_pool+0x2a48 与 +0x265d —— 两条分支各崩各的，模型自洽：
   旧的先崩掉约 6/10，剩下的 4/10 全被新的兜住，合起来 10/10。

   新用例就是你建议的那条路的补集，shutdown() 之后直接放一个 512 KiB 的块：

   static void test_pool_super_release_after_shutdown()
   {
       const size_t kSize = 512 * 1024;            // > 256 KiB ⇒ SUPER
       uvcpp::uvcpp_memory_pool pool;
       pool.init();
       pool.init_thread_cache();
   
       void* p = pool.allocate(kSize);
       TEST_ASSERT(p != nullptr, "前置：SUPER 块必须分配成功");
       std::memset(p, 0x5A, kSize);
   
       pool.shutdown();
       pool.deallocate(p);                         // shutdown_ 为真 ⇒ SUPER 那一支
   
       TEST_PASS();
   }

   大块比小块更容易把这条读变成硬崩：512 KiB free 之后 CRT 往往真的把页还给系统，同一个读当场
   变成访问违例，不像 64 字节块那样约一半的次数能蒙混过去。

   你指出的那条，我认

   81fe110 的提交信息写「每一条都先用失败用例或实测崩溃证出来才动代码」。对第 1、3 条成立，
   对第 2 条里的 default: 成立，对 shutdown_ 那两处不成立 —— 那条提交记录的验收写的是
   「页面堆门禁 94/94 绿、抓 0 个」，那是修复后的绿读数，不是对着变异体跑出来的对照读数。
   判据必须有对照组，这处我当时没做。已经在新用例的注释里把这段写清楚了。

   两条装置坑

   第 1 条（单目标构建不刷新测试目录那份 DLL）我这边也踩过，结论一样：copy_test_dlls 是
   ALL 目标，只有默认全量构建才会刷新那四份副本，--target xxx 不会 —— 判据要拿
   PE .text 段的哈希比，不能只看产物存在。第 2 条（MSYS2 PATH）记下了，谢谢。

   修复在 64fbe08（1.2.11-dev）。
3. Antruly commented on Oct 18, 2026

   

   Antruly

   on Oct 18, 2026

   Owner

   More actions

   这条可以关了 —— M3 缺判据那一格已经补上。

   • 用例：tests/expand/memory_pool_test.cpp:375 test_pool_super_release_after_shutdown()（64fbe08）。它走的就是你指出的那半边：init() → allocate(512 KiB)（> 256 KiB ⇒ SUPER）→ shutdown() → deallocate()，于是进 shutdown_ 为真时 SUPER 那一支；上面那条老用例只有 64 字节 TINY 块，够不到这里。
   • 为什么用大块：512 KiB 的块 free 之后 CRT 往往真的把页还给系统，release_bytes(block->size) 写在 free 之后那一读当场就是访问违例；64 字节块约有一半次数能蒙混过去（你那次 23/23 全绿就是这个原因）。
   • 注册名是 test_memory_pool（ctest -R test_memory_pool），本机现在绿。按你原来的做法把 M3 改回去，这条应当红 —— 如果你还想复核一次，现在有判据可用了。

   谢谢这套变异复核：M3 那两处此前确实全仓零覆盖，光读代码是看不出来的。
4. Antruly

   closed this as completedon Oct 18, 2026