开发者发现苹果Fsck_hfs工具存在安全漏洞

背景

在 macOS 系统中，HFS+ 是 Apple 长期使用的默认文件系统，其完整性检查工具 fsck_hfs 负责在启动或手动执行时验证文件系统结构的一致性。尽管 HFS+ 经过多年迭代，其底层代码仍存在一些未被充分测试的边缘情况。近期，一位技术爱好者在检查一块 24TB 的 HFS+ 外接硬盘时，遇到了一个看似矛盾的报错：“Couldn't read node #61432”，并伴随“not enough memory”错误。然而，该硬盘在 8GB RAM 的 Mac mini M1 上频繁出现此问题，而在更大内存的机器上却正常运行，这暗示问题并非出在硬件或数据损坏上，而是与系统资源管理有关。

核心内容

问题现象

当用户尝试对一块格式化为 Journaled HFS+ 的 24TB 外接硬盘执行 fsck_hfs 时，系统会报告以下错误：

** Checking extended attributes file.
Couldn't read node #61432
** The volume 24TB TOSHIBA could not be verified completely.
volume check failed with error 12
Error 12 is ENOMEM — "not enough memory."

这一错误在 8GB RAM 的 Mac mini M1 上稳定复现，但在 16GB 或更高内存的设备上则不会发生。

初步排查

1. 硬件排除：更换不同品牌、不同桥接芯片的硬盘后，错误依旧出现在相同的节点编号（#61432），说明问题不在硬件层面。
2. 数据完整性：通过 dmesg 和 fs_usage 监控磁盘 I/O，发现读取过程无错误，数据本身是完整的。
3. 文件系统结构：使用 xxd 等工具分析 HFS+ 卷头、B-tree 节点、位图等结构，确认文件系统本身无损坏。

深入分析

问题最终定位到 fsck_hfs 的内部缓存管理机制。具体而言：

• fsck_hfs 在启动时会预分配一个固定大小的缓存池，用于磁盘读取操作。缓存大小与系统 RAM 相关：

  • 4GB RAM → 512MB 缓存（16,384 个块）
  • 8GB RAM → 1GB 缓存（32,768 个块）
  • 16GB RAM → 2GB 缓存（65,536 个块）

• 在检查 HFS+ 的 Attributes B-tree 时，BTCheckUnusedNodes 函数会遍历所有标记为“空闲”的节点（共 65,341 个），并逐个读取以验证其内容是否为零。

• 每次读取都会触发 CacheLookup，该函数会为每个唯一的磁盘偏移量分配一个 Tag_t 结构，并从缓存池中获取一个 32KB 的缓冲区。

• 当缓存池中的所有块都被活跃标签占用，且 LRU（最近最少使用）列表为空时，CacheAllocBlock 无法分配新缓冲区，进而返回 ENOMEM 错误。

根本原因

问题并非系统 RAM 不足，而是 fsck_hfs 内部的缓存管理元数据耗尽。由于 LRU 淘汰机制未能及时回收不再使用的标签，导致缓存池在扫描过程中被“锁死”，最终触发虚假的内存不足错误。

关键要点

• 问题本质：fsck_hfs 的缓存管理机制存在缺陷，导致在特定条件下（如大卷、大量空闲节点）缓存池耗尽。
• 复现条件：
  • 文件系统为 HFS+，且包含大量空闲节点（如 24TB 卷）。
  • 系统 RAM 为 8GB 或更低（缓存池较小）。
• 非硬件问题：错误与硬盘本身无关，更换不同硬件后问题依旧。
• 非数据损坏：文件系统结构完整，数据无损坏。
• 内存假象：报错“not enough memory”并非系统 RAM 不足，而是内部缓存管理元数据耗尽。
• 可修复性：通过修改 CacheLookup 和 LRU 管理逻辑，优化缓存回收机制，可解决此问题。

意义与影响

对用户的意义

• 数据安全性：用户无需担心硬盘数据损坏或硬件故障，问题仅影响文件系统检查工具的正常运行。
• 操作建议：在遇到类似错误时，可尝试在更大内存的设备上运行 fsck_hfs，或忽略该错误（若文件系统其他部分验证通过）。

对开发者的启示

• 边缘场景测试：即使经过多年迭代的成熟系统，仍可能存在未被充分测试的边缘情况。建议在开发过程中覆盖更多极端场景（如超大卷、大量空闲节点）。
• 缓存管理优化：内部资源管理机制（如缓存、LRU 淘汰）需要更精细的设计，避免因元数据耗尽导致虚假错误。
• 错误信息准确性：报错“not enough memory”容易误导用户，应更明确地区分系统资源与内部管理资源的耗尽。

对 Apple 的影响

• 开源贡献：Apple 开源了 HFS+ 代码，社区可通过贡献补丁帮助修复此类问题。
• 文件系统演进：随着 APFS 的普及，HFS+ 的维护优先级可能降低，但此类问题仍值得解决，以保障现有用户的体验。

总结

这一事件揭示了即使是最成熟的系统组件，也可能在特定条件下暴露出设计缺陷。通过深入分析和社区协作，不仅可以解决具体问题，还能为未来系统开发提供宝贵经验。