Rust 跨语言内存所有权审计：用 rust-review 的 FOREIGNDROP 检出 Drop 误用 Rust 分配器释放 FFI 内存-育师

AI 技能
AI 插件
应用安全
网络安全
AI 评测

【免费下载链接】skills

Trail of Bits Claude Code skills for security research, vulnerability detection, and audit workflows

项目地址：https://gitcode.com/gh_mirrors/skills8/skills

导读

本文深入讲解 Trail of Bits rust-review 插件中foreign-drop-finder这一安全审计范式（Finding ID 前缀FOREIGNDROP）：当 Rust 结构体包装了由 C 语言或其他语言分配器（libc::malloc、g_malloc、CoTaskMemAlloc、CUDA、语言 VM 等）分配的内存，却在其Drop实现中把释放动作路由到 Rust 全局分配器时，就会产生分配器层面的非法释放（invalid free）。读完本文，你将掌握该缺陷的完整触发条件、误报排除规则、可直接运行的 ripgrep 搜索模式，以及让释放动作与分配动作严格配对的修复方案，并能理解它在 rust-review 全量审计流水线中的调度位置与去冲突规则。

缺陷本质：跨分配器的 invalid free

在 FFI（外部函数接口）场景下，内存的分配方与释放方必须严格配对。foreign-drop-finder检测的核心 bug 形态是：

一个 Rust 结构体包装了由外国分配器分配的指针 —— 例如libc::malloc、GLib 的g_malloc、CoreFoundation 的CFAllocator、Windows 的LocalAlloc/CoTaskMemAlloc、cudaMalloc、语言 VM 的分配器（PyO3 的Py、napi-rs 的JsObject、JNI），或某个 C 库自有的专用分配器。它的Drop实现（或通过Box/Vec自动派生的所有权逻辑）却把释放动作路由到了Rust 全局分配器（Box::from_raw、Vec::from_raw_parts、dealloc、mem::drop），而不是与之匹配的外国释放函数。

这在分配器层面构成非法释放：Rust 分配器把该指针交还给了它并不拥有的堆。常见的危险释放表达式如下：

// 危险：内存来自 libc::malloc，释放却走 Rust 全局分配器 impl Drop for CBuffer { fn drop(&mut self) { unsafe { let layout = Layout::array::<u8>(self.len).unwrap(); dealloc(self.ptr, layout); // ❌ invalid free // drop(Box::from_raw(self.ptr as *mut u8)); // ❌ 同样错误 // Vec::from_raw_parts(...) 自动 Drop // ❌ 同样错误 } } }

该文档还明确划定了反向边界：extern "C" fn接收一个由 Rust 分配的Box<T>并将其返回给 C的情形，属于 ABI/所有权转移规则范畴，不在本 finding 范围内。本 finding 只聚焦于 Rust 侧的Drop释放动作。

三条验证门：全部满足才算命中

foreign-drop-finder采用严格的验证门（Verification gates）机制，所有三条必须同时成立才能判定为FOREIGNDROP：

#	验证门	判定要点
1	结构体持有来自 FFI 的原始指针	字段类型为`mut T`/`const T`/`NonNull<T>`，且由外国分配器填充 —— 需要向上追溯构造函数或`From<*mut T>`实现，寻找`libc::malloc`、来自外部源的`CString::into_raw`、`CoTaskMemAlloc`等来源
2	释放路由指向 Rust 分配器	类型存在显式`impl Drop for X`，其函数体调用`Box::from_raw(self.ptr)`、`Vec::from_raw_parts(...)`、`alloc::dealloc(...)`、`drop(Box::from_raw(...))`，或通过一个错误分配器的`Box<T>`字段隐式释放
3	没有与之匹配的外国释放	在此之前/替代位置上没有调用外国分配器对应的`free`（如`libc::free`、`g_free`、`CFRelease`、`LocalFree`、`CoTaskMemFree`、`cudaFree`）

其中第 1 条强调"追踪证据"：不能只看字段类型，还要顺着构造函数和From<*mut T>的实现向上查找指针到底来自哪一方，这是区分真实命中与误报的关键证据链。

必须拒绝的误报清单

foreign-drop-finder同时给出了四类典型误报（FP），用于在审计时排除正确代码：

Rust 分配的指针走Box::from_raw释放—— 这正是正确的对称配对，不是缺陷；
外国分配的指针，其Drop调用的是外国释放函数—— 配对正确；
类型为#[repr(C)]且所有权已转移给 C 侧—— 本侧只是借用查看该指针（PhantomData<&'a T>），根本不需要Drop；
jemalloc/mimalloc被配置为 Rust 全局分配器—— 此时与Box::from_raw是自洽的对称关系。

这四条规则与验证门互补：验证门负责"确认命中"，FP 清单负责"排除误判"，两者共同保证审计结果的可信度。

搜索模式：可落地的 rg 正则与交叉引用

文档提供了四条可直接交给ripgrep执行的搜索种子，用于在两阶段审计中建立候选清单：

\bimpl\b[^{]*?\bDrop\s+for\s+\w+ \bBox::from_raw\b|\bVec::from_raw_parts\b|\bdealloc\s*\( \blibc::(malloc|calloc|realloc|strdup)\b CoTaskMemAlloc|LocalAlloc|GlobalAlloc[^:]|CFAllocator|g_malloc

命中后需要做交叉引用（Cross-reference）：找出"构造函数从外国分配器流出且Drop流入 Rust 分配器"的类型 —— 即把第一组正则（Drop实现）的命中和第三、四组正则（外国分配器）的命中按类型进行双向关联，只有两侧同时命中同一类型才进入验证门判定。

值得注意的是，在 rust-review 插件的 ffi-cross-language 集群提示中，FOREIGNDROP的 Phase A 阶段还有更宽的种子，包括extern "C"/CString::/#[repr(C)]/bindgen等，用于构建整个 FFI 安全域的候选库存，而 Phase B 阶段才按顺序逐类执行各 finder（FOREIGNDROP排在第 5 位）。这两层种子在仓库里是分工明确的：集群种子负责"圈定 FFI 安全域"，finder 种子负责"命中具体 bug 类"。

在 rust-review 流水线中的调度与去冲突

从集群 manifest 可以看到，foreign-drop（前缀FOREIGNDROP）注册在ffi-cross-language集群下，该集群的触发门是has_ffi能力标志；同时它被声明为**非整合（non-consolidated）**集群，意味着超过单 worker 负载上限时会被拆分成多个 chunk 并行执行。

根据 SKILL.md 的编排流程，has_ffi标志由以下探测正则决定（非空输出即置真），一旦置真整个 ffi-cross-language 集群才会被build_run_plan.py纳入计划：

grep -rlE 'extern\s+"(C|system|stdcall|...)"|\bextern\s+fn\b|extern\s+\{|#\[repr\((C|transparent)\b|\b(CString|CStr)\b|use\s+(libc|core::ffi|std::ffi|std::os::raw|cty)|\blibc::|\b(bindgen|cbindgen)\b|\bc_void\b' --include='*.rs' .

审计产生的每条 finding 以FOREIGNDROP-NNN.md的形式（带 YAML frontmatter）写入输出目录，之后由去重法官合并重复项、由误报/严重度法官给出fp_verdict、severity与attack_vector，最终汇入REPORT.md与REPORT.sarif。

FOREIGNDROP与同集群内外的相邻 bug 类存在明确的**去冲突（Deconfliction）**边界，审计时不可互相混报：

相邻 bug 类	前缀	与 FOREIGNDROP 的区分
opaque-pointer	`OPAQUEPTR`	处理的是句柄的身份/有效性混淆；而"不透明句柄的`Drop`释放了外国拥有的内存"应报`FOREIGNDROP`
cstring-dangling	`CSTRDANGLE`	Rust 拥有的`CStr`生命周期过早结束，对应"外国侧释放了 Rust 仍引用的缓冲区"时归`FOREIGNDROP`
invalid-free	`INVFREE`	纯 Rust 内部的`*ptr = new_val`对未初始化内存触发 Drop（见 invalid-free-finder），不含跨语言分配器错配
double-free	`DFREE`	同一 Rust 堆内存被`ptr::read`复制出双所有权（见 double-free-finder），不涉及外国分配器

修复方案：让释放与分配严格配对

文档给出的修复策略有两类，均围绕"释放动作必须匹配分配来源"这一核心原则：

方案一：把 Rust 释放换成外国分配器的匹配释放函数。将dealloc/Box::from_raw替换为libc::free、g_free、CoTaskMemFree等对应函数，并在// SAFETY:注释中记录分配器配对关系：

struct CBuffer { ptr: *mut u8, len: usize, } impl Drop for CBuffer { fn drop(&mut self) { unsafe { // SAFETY: ptr 由 libc::malloc 分配，必须且只能用 libc::free 释放 libc::free(self.ptr.cast()); } } }

方案二：在指针旁存储一个释放函数指针。当同一包装类型需要兼容多种分配来源时，可以在结构体里存一个unsafe fn drop_fn(*mut T)，在Drop中调用它，把"分配器配对"的决策集中到构造处：

struct ForeignBuf { ptr: *mut u8, len: usize, drop_fn: unsafe fn(*mut u8), // 构造时按分配来源注入匹配的释放函数 } impl Drop for ForeignBuf { fn drop(&mut self) { // SAFETY: drop_fn 与分配器配对，见构造点注释 unsafe { (self.drop_fn)(self.ptr) }; } }

两种方案的共同硬性要求是：在// SAFETY:注释中显式记录分配器配对关系，让后续维护者无需重新推断所有权来源。

防御性设计：在类型系统中封死错配

结合相邻 finder 与 FFI 最佳实践，可以在审计之外从设计层面消灭这类缺陷：

用 newtype 包装原始指针：将*mut T封装为NonNull<T>的新类型，让Drop的释放行为成为类型契约的一部分，而不是散落的unsafe代码；
利用Option<NonNull<T>>+take()：在显式close/free包装器中consume self，使释放后的句柄在编译期不可再被使用，把 use-after-free 变成编译错误（这正是 opaque-pointer-finder 推荐的句柄生命周期建模）；
正确处理所有权转移 API：C 侧若提供_take_ownership语义，Rust 侧应使用CString::into_raw等显式转移原语，而不是在Drop里对不拥有的指针做隐式释放；
必要时用ManuallyDrop/mem::forget：当所有权被刻意转移或双重释放风险存在时，显式中和某一路Drop，避免运行两次析构。