嵌入数百万设备中的文件系统被披露存在未修补漏洞

安全公司 runZero 披露了 FatFs 中的七个漏洞。FatFs 是一个小型文件系统库，允许设备读写 USB 驱动器和 SD 卡上使用的 FAT 和 exFAT 格式。
这些漏洞之所以重要，是因为 FatFs 几乎无处不在。它内置于运行安全摄像头、无人机、工业控制器、硬件加密钱包以及其他基于实时操作系统的设备的固件中。
在最严重受影响的系统上，攻击者只要将恶意制作的 USB 驱动器、SD 卡或更新文件插入设备，就能破坏其内存并运行自己的代码。
许多嵌入式设备缺乏手机和台式机上才有的内存保护，这就是为什么 runZero 表示"任何物理访问都会导致越狱"。一个公共信息亭、一个带 SD 卡槽的摄像头、一台 ATM 机，或者一台带 USB 端口的投票机，不应该在短暂的物理接触后就交出完全控制权，但在这里，它们确实会。
所有七个漏洞的工作方式基本相同。设备尝试读取一个被故意制作成畸形格式的存储卷或固件镜像，而 FatFs 错误地处理了这些恶意数据。runZero 将这批漏洞评级为 CVSS 中等到高等，没有严重等级。
最引人注目的漏洞是 CVE-2026-6682（CVSS 7.6），这是挂载 FAT32 卷的代码中的一个整数溢出漏洞。错误的计算会产生一个虚假的文件大小，后续代码会将其视为真实的读取长度。在真实硬件上，这可能导致内存损坏和代码执行。
以下是全部七个漏洞，按 runZero 的排名从高到低排列：

• CVE-2026-6682（7.6，高危）：FAT32 挂载时的整数溢出，导致内存损坏并可能执行代码。不仅可通过物理介质触发，某些固件更新也可触发。
• CVE-2026-6687（7.6，高危）：exFAT 卷标字段溢出一个小缓冲区，为攻击者提供了一个干净的内存损坏切入点。
• CVE-2026-6688（7.6，高危）：长文件名溢出许多项目在 FatFs 外围封装的代码，例如将 fno.fname 复制到固定缓冲区的 strcpy 操作。仅靠 FatFs 自身难以修复。
• CVE-2026-6685（6.1，中危）：处理碎片化卷上的缓存时出现数学计算回绕，可能导致数据静默损坏。
• CVE-2026-6683（4.6，中危）：exFAT 出现除零错误，导致设备崩溃。在更新流程中，可能使硬件变砖。某些固件更新也可触发。
• CVE-2026-6686（4.6，中危）：文件扩展超出其末尾，可能泄漏先前已删除文件的残留数据。
• CVE-2026-6684（4.6，中危）：畸形的 GPT 分区表（磁盘映射）在挂载时可能导致设备挂起。这是七个漏洞中唯一一个已在 FatFs R0.16 上游修复的。

难点在于：FatFs 由一位开发者在互联网的一个小角落维护，runZero 表示他们多次尝试联系该维护者，并联系了日本的 JPCERT/CC 协调中心，但均未得到回应。
根据 runZero 的说法，内存损坏漏洞没有上游修复方案，没有安全邮件列表，也没有办法让众多集成 FatFs 的产品知晓它们受到影响。更新有助于解决 GPT 挂起问题，因为当前版本已阻止该漏洞，但其余漏洞需要下游厂商自行修补。
runZero 列出了受影响平台，包括 Espressif ESP-IDF、STMicroelectronics STM32Cube、Zephyr、MicroPython、ArduPilot、RT-Thread、Mbed、Samsung TizenRT 以及 SWUpdate 更新程序。这便将问题推向了消费级 IoT、工业设备、无人机和加密钱包等下游领域。
截至 runZero 7月1日的披露，尚未有利用这些漏洞的攻击报告，此后也未出现。但利用材料已经公开：runZero 在配套仓库中发布了概念验证磁盘镜像、测试工具以及一个基于 QEMU 的可工作利用示例。
如果你构建涉及 FAT 或 exFAT 介质的固件，建议很直接：在你的产品中找到 FatFs 副本，审计其外围封装代码，仔细检查你如何处理文件名和文件大小，并计划打补丁。
如果你运行受影响的设备，请将物理端口和更新渠道视为攻击面：限制谁可以插入介质，并关注厂商的固件更新。
为什么这种情况一再发生
runZero 在 2017 年首次手动审计 FatFs，当时发现的可报告问题很少。2026年3月，该团队将一套现成的工具指向同一份代码：Visual Studio Code、处于"自动"模式的 GitHub Copilot，以及几个简单的提示词。
LLM 构建了一个模糊测试工具，该工具向代码输入畸形数据，直到出现问题。这发现了手动审计遗漏的漏洞，并帮助确认这些漏洞是可利用的。
这符合一个日益增长的趋势。2024年底，Google 的 Big Sleep 智能体在 SQLite 中发现了一个真实且可利用的内存漏洞，这是常规模糊测试未能发现的。
就在上个月，一个自主 AI 智能体在 FFmpeg（另一个广泛嵌入的 C 语言库）中发现了 21 个内存安全漏洞。runZero 的观点很直白：如果一个基本现成的 AI 管道都能发现这些漏洞，那么任何人都可以，因此默默保留这些漏洞并不能保护任何人。
修补问题也很熟悉。runZero 预计下游修复需要数年而非数天，而 PixieFail 就是先例：2024年，EDK II（许多 PC 和服务器品牌背后的固件）的网络启动代码中发现了一批九个漏洞，厂商修补缓慢。FatFs 面临同样的情况，且修复渠道更弱，因为根本没有响应式的上游。
关注两件事：FatFs 维护者是否会重新出现并发布补丁，以及集成它的各大平台厂商如何回应。在此之前，请假设大量出货设备正在使用没有修复方案的代码读取不受信任的存储介质。