CVE-2025-39737 in Linux
Tóm tắt
Bởi VulDB • 28/06/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
mm/kmemleak: tránh tình trạng khóa mềm (soft lockup) trong hàm __kmemleak_do_cleanup()
Một cảnh báo về khóa mềm (soft lockup warning) đã được quan sát thấy trên một hệ thống x86-64 có dung lượng bộ nhớ tương đối nhỏ, cụ thể là 16 GB, khi chạy kernel chế độ gỡ lỗi với tính năng kmemleak được bật.
watchdog: BUG: soft lockup - CPU#8 bị kẹt trong 33s! [kworker/8:1:134]
Hệ thống thử nghiệm đang chạy một tác vụ tải (workload) có sự kiện tháo nóng (hot unplug) xảy ra song song. Sau đó, kmemleak quyết định tự vô hiệu hóa do không thể phân bổ thêm các đối tượng kmemleak. Kernel chế độ gỡ lỗi này có cấu hình CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE được đặt là 40.000.
Tình trạng khóa mềm xảy ra trong hàm kmemleak_do_cleanup() khi các đối tượng kmemleak hiện có đang bị loại bỏ và xóa từng cái một theo vòng lặp thông qua workqueue. Trong trường hợp cụ thể này, có ít nhất 40.000 đối tượng cần được xử lý; do tốc độ chậm của kernel chế độ gỡ lỗi và thực tế là phải lấy (acquire) và giải phóng khóa raw_spinlock trong hàm __delete_object(), việc xử lý đúng cách tất cả các đối tượng này có thể mất một khoảng thời gian đáng kể.
Vì kmemleak đã bị vô hiệu hóa trong trường hợp này, quá trình loại bỏ và xóa đối tượng có thể được tối ưu hóa hơn nữa vì việc sử dụng khóa (locking) thực sự không cần thiết. Tuy nhiên, có lẽ không xứng đáng để đầu tư công sức vào việc tối ưu hóa cho một kịch bản biên (edge case) hiếm khi xảy ra như vậy. Do đó, giải pháp đơn giản là gọi hàm cond_resched() ở các khoảng thời gian định kỳ trong vòng lặp duyệt qua để tránh tình trạng khóa mềm.
VulDB is the best source for vulnerability data and more expert information about this specific topic.