news 2026/5/8 6:47:15

Linux内核的Rust“转正”后,惊爆首个安全漏洞!

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Linux内核的Rust“转正”后,惊爆首个安全漏洞!

编译 | 苏宓

出品 | CSDN(ID:CSDNnews)

都说 Rust 是内存安全的编程语言,但现实正在敲响警钟。

近日,Linux 内核维护者 Greg Kroah-Hartman 在邮件列表中确认,主线 Linux 内核中的一段 Rust 代码被正式登记为 CVE 漏洞。

这也是 Linux 内核 Rust 代码首次获得 CVE 编号,引发了社区的广泛关注。

Linux 内核 Rust 代码首次出现 CVE

这一漏洞出现在用 Rust 重写的 Android Binder 驱动(rust_binder)中。由于其中包含被标注出来的 unsafe Rust 代码,在特定并发场景下可能触发竞态条件,导致链表中 prev/next 指针发生内存破坏,最终引发内核崩溃。

Greg Kroah-Hartman 在公告中给出了问题代码的核心片段,其包含了如下 unsafe 操作:

// SAFETY: A `NodeDeath` is never inserted into the death list// of any node other than its owner, so it is either in this// death list or in no death list.unsafe { node_inner.death_list.remove(self) };

这个操作之所以是不安全的,是因为在修改链表元素的 prev/next 指针时,必须确保没有其他线程同时在并行访问或修改这些指针。

如果该节点确实存在于 remove 所操作的那个链表中,那么这是安全的,因为我们对该链表拥有独占访问权;如果节点根本不在任何链表中,也同样不会有问题。

但一旦节点实际上存在于另一个可能被并发访问的链表中,那么在执行 remove 操作时,就会引发数据竞争,直接破坏链表结构。

而遗憾的是,这里正好踩中了这种情况。

问题是如何触发的?

据 Greg Kroah-Hartman 的解释,问题发生在 Node::release 的执行流程中,大致步骤如下:

  1. 获取锁;

  2. 将原链表中的所有元素移动到一个位于栈上的本地链表;

  3. 释放锁;

  4. 遍历这个本地链表进行处理。

当其他线程同时在原始链表上使用这个 unsafe 的 remove 方法时,就会导致 prev/next 指针发生内存破坏,最终引发崩溃。

下面就是一次实际出现的崩溃示例:

针对这一问题,修复思路相对直接:修改 Node::release 的实现,不再先把元素整体移动到本地链表中,而是直接在原链表上逐个弹出并处理节点,从而避免并发访问时破坏链表结构。

影响范围

目前,Linux 内核 CVE 团队已为该问题分配编号CVE-2025-68260

该 CVE 影响的是 Linux 6.18 及之后的版本,也就是引入 Rust Binder 驱动之后的内核版本。

值得注意的是,这个问题目前“最多”只会导致系统崩溃,并不存在远程代码执行等更严重的安全风险。

对于“Rust 内核代码首次出现 CVE”这一节点性事件,Greg Kroah-Hartman 也给出了相对冷静的评价:

Rust 并不是一颗能够解决所有安全问题的“银弹”,但它确实能在很大程度上提供帮助。随着 Rust 在内核代码中的使用越来越广泛,它有望消除 Linux 内核中大量常见的漏洞类型。

......除了这个漏洞,同时也要注意,仅在今天,就有另外 159 个内核 CVE 是针对 C 语言代码部分的修复。因此,一如既往,想要整体上保持系统安全,最重要的仍然是及时升级到更新的内核版本。

另外,也有不少网友对于 Rust 的安全性发表自己的见解:

  • 如果 Rust 因为太死板,以至于必须使用 unsafe 才能解决问题,那责任仍然在 Rust 本身。你必须同时考虑安全 Rust 的行为以及必要的 unsafe 代码。

  • 任何认为仅仅把代码重写成 Rust 就能消除所有 bug 的人都是天真得无药可救的。尤其是考虑到 Rust 允许使用 unsafe 操作。这并不意味着 Rust 相较于 C 没有价值,只是它的价值并不是能完全消除 bug——而这也从来不是它所宣传的卖点。

那么,你怎么看?

参考:

https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/

https://news.ycombinator.com/item?id=46302621

推荐阅读:

GOBI 2025 全球开源商业创新大会顶级嘉宾阵容公开!4 大 Panel 火力全开

亏700亿美元、预算大砍30%、推迟两款头显:改名才4年,Meta元宇宙彻底“退烧”了?

首批鸿蒙极客:开发圈“金IP”的硬核实力

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/5/8 2:08:16

FaceFusion如何提升戴围巾遮挡下颌线的融合自然度?

FaceFusion如何提升戴围巾遮挡下颌线的融合自然度? 在短视频直播盛行的今天,虚拟形象与实时换脸技术已不再是影视特效的专属工具。越来越多的内容创作者希望在保持个人风格的同时,通过人脸替换实现角色扮演、隐私保护或创意表达。然而&#x…

作者头像 李华
网站建设 2026/5/8 1:05:38

19、机器学习在无线通信中的应用:5G 及未来发展

机器学习在无线通信中的应用:5G 及未来发展 1. 引言 未来的先进技术涵盖多个领域,如电子医疗应用、工业 4.0 和大规模机器人技术、全息远程呈现、智能环境中的普遍连接、三维大规模无人驾驶移动、增强现实(AR)和虚拟现实(VR)等。这些下一代技术有望提供高质量和高效的性…

作者头像 李华
网站建设 2026/5/8 2:08:16

33、6G 无线网络:架构、优势与挑战

6G 无线网络:架构、优势与挑战 1. 无线通信网络的发展历程 互联网已成为全球热门话题,无论性别、年龄、国家和学历,人们都在使用互联网以获取更好的服务。从第二代到第五代,无线网络发生了巨大变化,从基本的语音通话服务发展到视频通话等高级服务,吸引了众多用户。 无…

作者头像 李华
网站建设 2026/5/5 1:09:59

为什么顶尖团队都选方案B?,Open-AutoGLM更新适配效率深度对比分析

第一章:为什么顶尖团队都选方案B?在高并发系统架构的演进过程中,方案B因其卓越的可扩展性与容错能力,逐渐成为顶尖技术团队的首选。该方案通过异步消息驱动与服务解耦的设计理念,显著提升了系统的稳定性与响应速度。核…

作者头像 李华
网站建设 2026/5/7 18:23:36

Open-AutoGLM版本兼容性难题(效率下降80%的根源找到了)

第一章:Open-AutoGLM版本兼容性难题概述在深度学习与大语言模型快速演进的背景下,Open-AutoGLM作为一款开源自动化生成语言模型工具,正被广泛应用于文本生成、代码辅助和智能问答等场景。然而,随着其迭代速度加快,不同…

作者头像 李华