Rust 和 C/C++ 的内存安全 CVE 有何不同
CVE 是一个用于对软件安全漏洞进行分类和报告的标准数据库。有些漏洞源于简单的程序逻辑缺陷，但最棘手的那些往往是由内存不安全导致的，很容易被利用。本文关注的是后一类 CVE——它们如何被报告，以及在 Rust 和 C/C++ 之间的差异。
我经常看到有人拿 Rust 和 C/C++ 软件的 CVE 数量做比较，然后声称 Rust 并没有真正做到内存安全。当我向习惯 C/C++ 的程序员教授 Rust 时，也偶尔会遇到类似的观点。我认为，Rust 和 C/C++ 在处理内存安全相关的潜在漏洞时，存在着一个重要的差异——这个差异对不熟悉 Rust 工作机制的人来说可能并不明显。
首先，我必须澄清一点：在 Rust 中完全可能写出内存不安全和未定义行为（UB）的 bug。绝大多数情况下，这需要 unsafe 关键字。如果有人声称 Rust 程序完全不会出现 UB，那是不正确的。
一个「潜在」的 curl 漏洞
libcurl 是全世界使用最广泛、维护最出色的开源库之一。尽管最近不得不应对由 LLM 发现的大量 CVE 浪潮，开发者们仍然出色地维护着 curl 的安全性。那么，让我们做一个测试：
#include <curl/curl.h>
int main(void) {
curl_getenv(NULL);
}这段 5 行代码调用 curl_getenv 并传入 NULL，编译时没有任何警告。但执行时会产生段错误——一个内存安全 bug，从而构成一个潜在漏洞。
当然，这个程序是人为简化的。但它揭示了一个关键问题：在 C 中，由于类型系统能力有限，无法精确描述 API 的契约（如要求参数不能为 NULL）。库作者通常也不会费心去描述所有可能的错误使用方式。此外，在 C/C++ 中意外触发 UB 实在太简单了——如果每个可能产生漏洞的方式都报告为 CVE，大多数 C/C++ 库会被数百万个 CVE 淹没。
因此，在 C 和 C++ 中，我们只为特定的库误用创建 CVE，而不是为可以被误用的 API 存在本身创建 CVE。
在 Rust 中有什么不同？
假设 Rust 的网络库 hyper 有一个类似的函数，我这样调用：
fn main() {
hyper::foo(None);
}如果这段程序段错误了——这会是一个 hyper 的 CVE 吗？是的，绝对会。 这个程序不包含任何 unsafe 块，所以如果发生内存错误，那一定是 hyper 库本身的健全性 bug。
关键的区别在于：在 Rust 中，如果能以任何可想象的方式使用一个库而导致内存错误，且用户代码中不需要使用 unsafe，那么这永远都是库的 bug，而不是用户代码的 bug。这就是「不健全」（unsound）API 的含义——在 safe Rust 中，存在一种错误使用它的方式会导致内存问题。
这意味着 Rust 中报告的某些 CVE 比 C/C++ 中的要「严格」得多。如果我们对 C 应用同样的逻辑，那么 curl_getenv 应该被标记为 curl 的 CVE，因为存在一种使用方式会导致内存错误。但当然，这在 C 中并不合理，因为所有 C 代码隐式地都是 unsafe 的。
「我正确使用了这个函数吗？」——在 Rust 中答案非常简单：
- 如果调用的函数没有标记
unsafe，答案是「是的」。你不可能错误地使用它。 - 如果调用的函数是
unsafe，调用处必须用unsafe { }包裹，代码审查时立刻就能看出这个地方有潜在危险。
答案的第一部分正是 Rust 的内存安全性在实践中得以扩展的原因。如果你不在代码中使用 unsafe，任何潜在的内存不安全原因都不是你的错。如果一个库没有暴露任何 unsafe 接口，你不可能以导致内存错误的方式使用它，除非该库内部有 bug——而一旦 bug 被修复，所有使用者又自动安全了。
这就是 Rust 和 C/C++ 之间的核心差异。尽管 curl 的开发者们出色地构建了一个健壮的 C 库，但数以百万计使用它的 C 程序仍然可以仅仅因为「拿错了」就轻易引入内存不安全问题，而 curl 开发者对此没有任何办法阻止。
结论
直接比较 Rust 和 C/C++ 每行代码的 CVE 数量是极具误导性的。Rust 对 CVE 的定义更加严格——任何 safe API 的可能误用都算作库的 bug——而 C/C++ 中的类似情况只会被视为用户代码的问题。在比较系统编程语言的内存安全性时，我们必须考虑到这一点。
原文出处：https://kobzol.github.io/rust/2026/06/15/how-memory-safety-cves-differ-between-rust-and-c-cpp.html
