FatFs 中的七个漏洞使 IoT 和嵌入式设备面临风险

runZero 在 FatFs 中发现了 7 个漏洞，FatFs 是用于 IoT 和嵌入式设备的文件系统。这些漏洞可通过精心制作的存储介质导致内存损坏、崩溃或数据泄露。
网络安全公司 runZero 披露了 FatFs 中的七个漏洞。FatFs 是一个紧凑的开源库，允许嵌入式设备读写 FAT 和 exFAT 格式的存储介质，与 USB 驱动器和 SD 卡使用的格式相同。严重性评级从 CVSS 中等到高等。
该项目重新审视了 2017 年对 FatFs 驱动器的安全审计，当时的手动测试和模糊测试仅发现了小问题。2026 年 3 月，该团队使用 Visual Studio Code 和处于自动模式的 GitHub Copilot，配合简单的提示词且没有使用自定义工具，重复了分析。结果出乎意料：之前遗漏的问题变得容易发现。AI 帮助自动生成模糊测试输入，甚至验证了在不同嵌入式环境中的可利用性，将曾经的手动、耗时过程转变为更加自动化和高效的方式。
这些漏洞影响多个平台，包括 Espressif ESP-IDF、STMicroelectronics STM32Cube、Zephyr RTOS、MicroPython、ArduPilot、RT-Thread、Mbed、Samsung TizenRT 和 SWUpdate。这些平台的下游是消费级 IoT 设备、工业控制器、无人机、硬件加密钱包等。
大多数集成 FatFs 的设备缺乏手机和台式机视为理所当然的内存保护，例如 ASLR。
报告指出："对于在这些平台上构建产品的供应商来说，情况很简单：任何物理访问都会导致越狱，尤其是在缺乏地址空间布局随机化和内存保护的情况下。对于其他人来说，存在大量设备，公众的短暂物理接触不应导致完全被入侵。例如，带 SD 卡存储的安全摄像头、带 USB 文件读取器的投票机、ATM 机，以及几乎所有你期望人们触摸的带屏幕的设备。"
一个带 SD 卡槽的安全摄像头、一个带 USB 读取器的投票机、一台 ATM 机、一个公共信息亭：这些都不应该向任何插入驱动器的人交出完全控制权，但在运行易受攻击的 FatFs 代码的未修补硬件上，这就是风险所在。
所有七个漏洞共享相同的触发方式：设备读取精心制作的存储卷或固件镜像，FatFs 错误处理了畸形数据，然后坏事随之发生。其中两个 CVE（CVE-2026-6682 和 CVE-2026-6683）也与空中固件更新过程有关，这完全将攻击面扩展到了物理介质之外。
以下是七个漏洞的详细信息：

• CVE-2026-6682（CVSS 7.6，高危）：mount_volume() 中的 FAT32 整数溢出可产生攻击者控制的文件大小元数据。下游代码可能将其视为读取长度，导致堆或栈损坏并可能执行代码。
• CVE-2026-6687（CVSS 7.6，高危）：f_getlabel() 中的 exFAT 卷标长度栈溢出，当标签字段未正确限制时，允许向标签缓冲区进行超长写入。这可能导致嵌入式固件中直接的内存损坏。
• CVE-2026-6688（CVSS 7.6，高危）：下游调用者中的长文件名溢出，其中 fno.fname 超过固定大小的缓冲区。这通常在使用 strcpy 或 sprintf 的封装代码中发生，并在很大程度上取决于固件如何处理文件名。
• CVE-2026-6685（CVSS 6.1，中危）：在碎片化卷上的脏缓存处理中，无符号减法回绕可能导致内存损坏或静默数据损坏，这在日志记录和控制系统中尤其危险。
• CVE-2026-6683（CVSS 4.6，中危）：由精心制作的介质触发的 exFAT 除零错误，在同步/写入路径中导致可靠的崩溃，并在固件更新场景中可能导致设备变砖。
• CVE-2026-6686（CVSS 4.6，中危）：将文件扩展到 EOF 之外时，未初始化的簇暴露可能泄漏先前已删除文件中的陈旧数据，造成信息泄露风险。
• CVE-2026-6684（CVSS 4.6，中危）：R0.16 之前版本中的 GPT 分区扫描循环可能导致无界扫描，造成启动时拒绝服务。该漏洞已在上游修复，但仍存在于较旧的嵌入式部署中。

FatFs 由一位开发者维护。runZero 多次尝试联系维护者，并让 JPCERT/CC 参与了协调过程。两次努力均未得到回应。对于七个 CVE 中的六个，没有上游补丁。唯一可用的修复是 R0.16 中解决的 GPT 扫描问题，即使如此，也需要下游供应商更新其 vended 副本。
最后一个细节是问题的关键。
报告继续说道："FatFs 就是这样的组件之一。它紧凑、有用，并且被到处复制。这对于快速出货产品来说很好，但当内存安全问题出现在愉快地摄入不受信任介质的解析器相关代码中时，就不那么好了。从披露和修复的角度来看，这种组件处理起来更具挑战性，因为几乎每个人最终都会进行本地化的 vended 修改。因此，上游补丁在整合之前必须非常仔细地验证。"
即使最终出现修复方案，每个与上游存在差异的供应商也必须针对自己的修改进行验证，然后才能发布。PixieFail 的先例（2024 年披露的 EDK II 网络启动代码中的九个漏洞）表明，这个过程需要数年而非数周，而 FatFs 的修复渠道更弱，因为根本没有响应式的上游。
runZero 在配套仓库 github.com/runZeroInc/vulns-2026-fatfs-chance 中发布了概念验证磁盘镜像、测试工具以及一个基于 QEMU 的可工作利用演示。截至 7 月 1 日披露日期，尚未有利用这些漏洞的攻击报告。
如果你出货或运行受影响的产品，该怎么办？
如果你构建涉及 FAT 或 exFAT 存储的固件，当前的工作是：找到你的 vended 版 FatFs 副本，审计其外围封装代码，检查你的代码如何处理文件名和文件大小，并计划打补丁。特别注意任何将 fno.fname 复制到固定大小缓冲区的代码。如果你运行而非构建受影响的设备，请将物理端口和固件更新渠道视为攻击面：限制谁可以插入介质，监控供应商的安全公告，并在供应商发布固件更新时进行应用。
runZero 提出的更广泛观点值得深思。在 2026 年保持这些漏洞的沉默将毫无意义，因为发现它们的工具现已广泛可用。对这种现实的正确回应是披露、尽可能协调，以及发布信息以让防御者获得先机。