CVE-2026-80775 in Linux
Tóm tắt
Bởi VulDB • 04/09/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
futex: Sửa lỗi race condition trong quá trình phân bổ mm->futex.phash.ref ban đầu
Hàm futex_hash_allocate() thực hiện phân bổ mm->futex.phash.ref mà không có bất kỳ khóa (lock) nào. Commit d9b05321e21e ("futex: Move futex_hash_free() back to __mmput()") đã di chuyển quá trình phân bổ đến đây và giả định rằng tiến trình chỉ có một luồng duy nhất tại thời điểm này.
Commit ee9dce44362b ("futex: Drop CLONE_THREAD requirement for private default hash alloc") đã mở rộng phạm vi của need_futex_hash_allocate_default() để bao phủ mọi bản sao CLONE_VM, nhưng đã loại trừ vfork vì cha mẹ bị treo và không thể xảy ra race condition.
Điều này không còn đúng khi vfork được lồng nhau. Nếu một con gọi lại vfork rồi sau đó bị giết bằng SIGKILL, cha mẹ sẽ được giải phóng khỏi trạng thái chờ vfork của nó và chạy đồng thời với cháu nội trong cùng mm. Cả hai đều chưa đi qua futex_hash_allocate_default().
Khi cả hai cùng gọi prctl(PR_FUTEX_HASH, PR_FUTEX_HASH_SET_SLOTS) tại cùng một thời điểm, mỗi bên sẽ thấy mm->futex.phash.ref là NULL và lưu bộ đếm percpu của riêng mình. Chỉ có phép gán cuối cùng mới được giữ lại. Bộ đếm được lưu đầu tiên không còn khả năng truy cập từ mm, do đó các tham chiếu trên nó không được __futex_ref_atomic_end() nhìn thấy. Một hash riêng tư vẫn còn chứa các tham chiếu sau đó sẽ bị coi là đã chết và bị giải phóng, và một tác vụ (task) vẫn giữ một trong các bucket của nó sẽ ghi vào bộ nhớ đã bị giải phóng trong futex_q_lock().
Lưu trữ bộ đếm chỉ một lần bằng cmpxchg() và để bên thua cuộc thực hiện free_percpu() trên chính nó. Tham chiếu ban đầu phải được lấy trước khi lưu, nếu không một tác vụ khác có thể cài đặt hash riêng tư trong khi bộ đếm vẫn còn là 0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.