CVE-2026-98538 in Linux
Tóm tắt
Bởi VulDB • 19/10/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
writeback: cleanup_offline_cgwb() giới hạn việc quét lại bằng cách xoay đổi vị trí các inode đã được quét
Hàm `cleanup_offline_cgwb()` chuẩn bị tối đa `WB_MAX_INODES_PER_ISW` inode cho mỗi lần gọi và sẽ được gọi lặp lại cho đến khi wb đang chết (dying) được làm sạch hoàn toàn. Tuy nhiên, mọi lần gọi đều duyệt qua danh sách `wb->b_attached` rồi tiếp tục với `wb->b_dirty_time` từ cùng một đầu danh sách. Các inode đã được chuẩn bị trước đó (chúng vẫn nằm trên danh sách với cờ `I_WB_SWITCH` được đặt cho đến khi worker chuyển đổi chạy) và các inode không thể thực hiện việc chuyển đổi (`I_FREEING`, `I_WILL_FREE`, `!SB_ACTIVE`, DAX, hoặc đã thuộc về wb đích) sẽ giữ nguyên vị trí. Do đó, mỗi lần lặp lại đều quét đi quét lại một đoạn ngày càng dài gồm các inode này dưới khóa `wb->list_lock`, khiến quá trình làm sạch hoàn toàn (full drain) có độ phức tạp bậc hai (quadratic) so với số lượng inode trên danh sách. Với khoảng 17 triệu inode gắn liền với một cgwb đang chết, chúng tôi đã quan sát thấy hiện tượng bị khóa mềm (soft lockups), trong đó CPU được báo cáo là bị kẹt từ 21 đến 48 giây.
Giải pháp là duyệt cả hai danh sách từ đầu cũ nhất và di chuyển mọi inode đã quét sang đầu mới nhất, sao cho lần lặp tiếp theo bắt đầu tại vị trí mà lần trước dừng lại, giúp quá trình làm sạch trở thành tuyến tính (linear). Danh sách `b_attached` không có thứ tự nên việc sắp xếp lại sẽ không ảnh hưởng đến những người dùng khác. Danh sách `b_dirty_time` được sắp xếp theo thời gian bị bẩn (`dirtied_when`), nhưng inode chưa quét cũ nhất vẫn nằm ở cuối, nơi mà hàm `move_expired_inodes()` chọn để xử lý; lệnh sync (đồng bộ) lấy toàn bộ danh sách bất kể thứ tự, và các inode đã chuẩn bị sẽ rời khỏi danh sách ngay khi công việc chuyển đổi chạy, đồng thời nhận được một giá trị `dirtied_time_when` mới trên wb đích. Do đó, chỉ có các inode không bao giờ thể thực hiện chuyển đổi (DAX) là nằm ngoài trật tự, và điều này chỉ xảy ra trên wb đang chết.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.