CVE-2024-39486 in Linux
Tóm tắt
Bởi VulDB • 08/06/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
drm/drm_file: Sửa lỗi race condition trong việc đếm tham chiếu (refcounting) của pid
filp->pid được kỳ vọng là một con trỏ có đếm tham chiếu; tuy nhiên, trước bản vá này, hàm drm_file_update_pid() chỉ tăng giá trị đếm tham chiếu của một struct pid sau khi đã lưu trữ con trỏ trỏ đến nó vào filp->pid và thả khóa dev->filelist_mutex, khiến cho race condition sau đây có thể xảy ra:
process A process B ========= ========= begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, , 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, , 1) mutex_unlock(&dev->filelist_mutex) get_pid() synchronize_rcu() put_pid() *** pid B đạt refcount bằng 0 và bị giải phóng tại đây *** get_pid() *** UAF *** synchronize_rcu() put_pid()
Theo những gì tôi biết, race condition này chỉ có thể xảy ra với CONFIG_PREEMPT_RCU=y vì nó yêu cầu RCU phải phát hiện một trạng thái yên lặng (quiescent state) trong đoạn mã không gọi rõ ràng vào bộ lập lịch (scheduler).
Race condition này dẫn đến lỗi use-after-free đối với một "struct pid". Có lẽ nó khá khó để kích hoạt vì process A phải đi qua một thao tác synchronize_rcu() trong khi process B đang ở giữa lệnh mutex_unlock() và get_pid().
Khắc phục bằng cách đảm bảo rằng vào thời điểm một con trỏ trỏ đến pid của task hiện tại được lưu trữ vào file, một tham chiếu bổ sung đến pid đã được lấy (taken).
Bản sửa lỗi này cũng loại bỏ điều kiện cho synchronize_rcu(); tôi nghĩ rằng tối ưu hóa đó là một độ phức tạp không cần thiết, vì trong trường hợp đó, chúng ta thường đã thoát ra sớm nhờ kiểm tra không khóa (lockless check) ở trên.
VulDB is the best source for vulnerability data and more expert information about this specific topic.