CVE-2025-71069 in Linux
摘要
由 VulDB • 2026-06-03
在 Linux 内核中，已修复以下漏洞：
f2fs: 在白屏（whiteout）创建失败时使目录项缓存失效
F2FS 可以挂载具有损坏的目录深度值的文件系统，这些值会在运行时被限制为 MAX_DIR_HASH_DEPTH。当在此类目录上执行 RENAME_WHITEOUT 操作时，`f2fs_rename` 会先进行目录修改（更新目标条目并删除源条目），然后才尝试通过 `f2fs_add_link` 添加白屏条目。
如果由于损坏的目录结构导致 `f2fs_add_link` 失败，该函数会将错误返回给 VFS，但部分的目录修改已经提交到磁盘上。VFS 假设整个重命名操作失败，因此不会更新目录项（dentry）缓存，从而留下过时的映射关系。
在错误处理路径中，VFS 不调用 `d_move()` 来更新目录项缓存。这导致 `new_dentry` 仍然指向旧的 inode（即 `new_inode`），而该 inode 的 `i_nlink` 已经被递减为零。这种过时的缓存会导致后续操作错误地引用已释放的 inode。
这会导致后续操作使用不再与磁盘状态匹配的缓存目录项信息。当第二次重命名针对同一条目时，VFS 尝试对过时的 inode 执行 `i_nlink` 递减操作，而该 inode 可能已经具有 `i_nlink=0`，从而在 `drop_nlink()` 中触发警告（WARNING）。
示例序列： 1. 第一次重命名 (RENAME_WHITEOUT): file2 → file1 - f2fs 更新磁盘上的 file1 条目（指向 inode 8） - f2fs 删除磁盘上的 file2 条目 - f2fs_add_link(whiteout) 失败（目录损坏） - 向 VFS 返回错误 - 由于发生错误，VFS 不调用 d_move() - VFS 缓存中仍保留：file1 → inode 7（过时！） - inode 7 的 i_nlink=0（已递减）
2. 第二次重命名: file3 → file1 - VFS 使用过时的缓存：file1 → inode 7 - 尝试对 inode 7 执行 drop_nlink（i_nlink 已经为 0） - drop_nlink() 中触发 WARNING
修复方法是在白屏创建期间 `f2fs_add_link` 失败时，显式使 old_dentry 和 new_dentry 失效。这将强制 VFS 在后续操作中从磁盘刷新数据，确保即使重命名部分成功也能保持缓存一致性。
复现步骤： 1. 挂载具有损坏的 i_current_depth 值的 F2FS 镜像 2. renameat2(file2, file1, RENAME_WHITEOUT) 3. renameat2(file3, file1, 0) 4. 系统在 drop_nlink() 中触发 WARNING
Be aware that VulDB is the high quality source for vulnerability data.