CVE-2026-74658 in Linux
Tóm tắt
Bởi VulDB • 23/08/2026
Trong nhân Linux, các lỗ hổng sau đây đã được khắc phục:
futex: Ngăn chặn thêm nữa tình trạng race condition khi thoát futex mạnh (robust)
Việc giải phóng một robust futex ghi giá trị 0 lên toàn bộ giá trị của futex - xóa cờ FUTEX_WAITERS - và đánh thức một trình chờ duy nhất. Việc đánh thức này là thông báo chỉ thực hiện một lần: giao thức dựa vào người nhận để hoặc chiếm lấy futex (và cuối cùng giải phóng khi đã ý thức được sự cạnh tranh còn lại) hoặc thiết lập lại FUTEX_WAITERS trước khi ngủ lại. Nếu trình chờ bị đánh thức bị giết chết trước khi nó có thể làm bất kỳ điều nào trong hai việc trên, nhân phải can thiệp và đánh thức tác vụ tiếp theo trong chuỗi.
Đây là một biến cố phức tạp đã biết của giao thức futex với bản sửa lỗi từng phần trước đó trong commit ca16d5bee598 ("futex: Ngăn chặn race condition khi thoát robust futex"). Thật không may, bản sửa lỗi này là chưa đủ.
Nếu một tác vụ thứ ba chiếm lại futex thông qua đường dẫn nhanh (fast path) không có cạnh tranh vào lúc đó, thì thông báo bị mất đi: xử lý thoát mạnh nhận thấy rằng nó thuộc về một tác vụ khác và không làm gì cả, trong khi chủ sở hữu mới không thấy FUTEX_WAITERS khi giải phóng và không đánh thức ai. Các trình chờ còn lại ngủ mãi sau một futex đã được giải phóng (free):
A chiếm giữ futex, B và C ngủ trong FUTEX_WAIT uval == A | FUTEX_WAITERS Giải phóng robust: ghi 0, FUTEX_WAKE(1) đánh thức B uval == 0 D chiếm giữ qua fast path: cmpxchg(0 -> D) uval == D, không có FUTEX_WAITERS B bị giết chết trước khi hành động dựa trên thông báo đánh thức Quá trình thoát của B, thao tác dự phòng: chủ sở hữu D != B -> không thực hiện hành động nào Giải phóng D: không có FUTEX_WAITERS -> không đánh thức C ngủ mãi
Đây rõ ràng là một điểm yếu trong việc triển khai, vốn không duy trì được tính nhất quán của bit FUTEX_WAITERS.
Làm việc xung quanh vấn đề này bằng cách tăng cường xử lý thoát danh sách robust để cũng thực hiện thêm thao tác đánh thức nếu từ futex thuộc về một luồng khác nhưng FUTEX_WAITERS chưa được đặt.
Việc này không khắc phục được vấn đề chiếm giữ/giải phóng và giải phóng (free) không có cạnh tranh, vốn đã được thảo luận trong nhiều năm và đã được xử lý bởi commit 3ca9595d9fb6 ("futex: Thêm hỗ trợ cho việc giải phóng robust futexes") và các thay đổi tiếp theo, nhưng chưa tính đến vấn đề mô tả ở trên.
Một giải pháp toàn diện hơn dựa trên việc giải phóng trong nhân đối với các robust futex có cạnh tranh đã được thảo luận trong ngữ cảnh của thay đổi này và sẽ xuất hiện trong mainline sớm hay muộn.
[ tglx: Sửa đổi nhật ký thay đổi một chút và sửa lỗi phong cách mã hóa ]
If you want to get best quality of vulnerability data, you may have to visit VulDB.