CVE-2026-80776 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 hàm futex_pivot_pending() khi thực hiện thay đổi kích thước (resize) bảng băm riêng tư (private hash).
Một tiến trình đang thực hiện thao tác thay đổi kích thước bảng băm riêng tư tùy chỉnh có thể bị treo ở trạng thái ngủ không ngắt được (uninterruptible sleep) một cách vô hạn. Bộ phát hiện tiến trình treo (hung-task detector) báo cáo:
INFO: task futex-resizer:314 blocked for more than 10 seconds. task:futex-resizer state:D stack:14824 pid:314 tgid:312 ppid:311
Call Trace: __schedule+0x521/0xf30 schedule+0x22/0xa0 futex_hash_allocate+0x3db/0x490 __do_sys_prctl+0x6f5/0xbd0 do_syscall_64+0xf9/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Kernel panic - not syncing: hung_task: blocked tasks
Hàm futex_pivot_pending() cho phép yêu cầu thay đổi kích thước tiếp tục khi không có bảng băm mới (hash_new == NULL) hoặc khi tham chiếu đếm của bảng băm hiện tại đã đạt về 0.
Sau sự kiện đánh thức dựa trên tham chiếu cuối cùng, một tiến trình futex khác có thể hoàn tất quá trình chuyển đổi giữa hai quan sát:
T1 T2
futex_hash_allocate() wait_var_event(mm, ...) futex_pivot_pending(mm) hash_new != NULL futex_hash() futex_ref_get(old) -> false futex_pivot_hash(mm) hash_new = NULL __futex_pivot_hash(mm, new) rcu_assign_pointer(hash, new) fph = rcu_dereference(hash) /* mới */ futex_ref_is_dead(fph) -> false schedule()
Quá trình chuyển đổi thay đổi trạng thái từ hash_new != NULL với bảng băm hiện tại đã chết sang hash_new == NULL với bảng băm hiện tại còn sống. Vì hàm futex_pivot_pending() đọc giá trị của hash_new và hash mà không có cơ chế đồng bộ hóa, tiến trình thực hiện thay đổi kích thước có thể quan sát thấy hash_new ở trạng thái tiền-chuyển đổi (pre-pivot) và hash ở trạng thái hậu-chuyển đổi (post-pivot), khiến futex_pivot_pending() trả về false mặc dù quá trình chuyển đổi đã hoàn tất. Tiến trình sau đó đi vào ngủ trong khi sự kiện đánh thức đã bị tiêu thụ trước đó.
Đồng bộ hóa các phép đọc trạng thái trong hàm futex_pivot_pending() bằng cách sử dụng khóa futex_mm_phash::lock. Điều này đảm bảo rằng futex_pivot_pending() quan sát hash_new và hash một cách nguyên tử, loại bỏ hoàn toàn Race Condition.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.