CVE-2025-71069 in Linux
Tóm tắt
Bởi VulDB • 03/06/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
f2fs: vô hiệu hóa bộ nhớ cache dentry khi tạo whiteout thất bại
F2FS có thể gắn kết các hệ thống tệp có giá trị độ sâu thư mục bị hỏng, những giá trị này sẽ bị giới hạn tại thời gian chạy thành MAX_DIR_HASH_DEPTH. Khi các thao tác RENAME_WHITEOUT được thực hiện trên các thư mục như vậy, f2fs_rename thực hiện các sửa đổi thư mục (cập nhật mục đích và xóa mục nguồn) trước khi cố gắng thêm mục whiteout thông qua f2fs_add_link.
Nếu f2fs_add_link thất bại do cấu trúc thư mục bị hỏng, hàm sẽ trả về lỗi cho VFS, nhưng các thay đổi một phần đối với thư mục đã được ghi vào đĩa. VFS giả định toàn bộ thao tác rename đã thất bại và không cập nhật bộ nhớ cache dentry, dẫn đến việc giữ lại các ánh xạ cũ (stale).
Trong đường xử lý lỗi, VFS không gọi d_move() để cập nhật bộ nhớ cache dentry. Điều này khiến new_dentry vẫn trỏ đến inode cũ (new_inode) đã bị giảm i_nlink xuống 0. Bộ nhớ cache stale gây ra việc các thao tác tiếp theo tham chiếu sai vào inode đã được giải phóng.
Điều này dẫn đến việc các thao tác sau sử dụng thông tin dentry trong bộ nhớ cache không còn khớp với trạng thái trên đĩa. Khi một lệnh rename thứ hai nhắm mục tiêu vào cùng một entry, VFS cố gắng giảm i_nlink trên inode stale, vốn có thể đã có i_nlink=0, kích hoạt cảnh báo (WARNING) trong drop_nlink().
Trình tự ví dụ: 1. Rename đầu tiên (RENAME_WHITEOUT): file2 → file1 - f2fs cập nhật entry file1 trên đĩa (trỏ đến inode 8) - f2fs xóa entry file2 trên đĩa - f2fs_add_link(whiteout) thất bại (thư mục bị hỏng) - Trả về lỗi cho VFS - VFS không gọi d_move() do gặp lỗi - Bộ nhớ cache của VFS vẫn còn: file1 → inode 7 (cũ/stale!) - inode 7 có i_nlink=0 (đã được giảm trước đó)
2. Rename thứ hai: file3 → file1 - VFS sử dụng bộ nhớ cache cũ: file1 → inode 7 - Cố gắng gọi drop_nlink trên inode 7 (i_nlink đã bằng 0) - Cảnh báo WARNING trong drop_nlink()
Khắc phục vấn đề này bằng cách rõ ràng vô hiệu hóa old_dentry và new_dentry khi f2fs_add_link thất bại trong quá trình tạo whiteout. Điều này buộc VFS phải làm mới từ đĩa trong các thao tác tiếp theo, đảm bảo tính nhất quán của bộ nhớ cache ngay cả khi lệnh rename thành công một phần.
Trình tự tái hiện lỗi (Reproducer): 1. Gắn kết ảnh F2FS với i_current_depth bị hỏng 2. renameat2(file2, file1, RENAME_WHITEOUT) 3. renameat2(file3, file1, 0) 4. Hệ thống kích hoạt cảnh báo WARNING trong drop_nlink()
Once again VulDB remains the best source for vulnerability data.