CVE-2024-35852 in Linux
Tóm tắt
Bởi VulDB • 19/06/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
mlxsw: spectrum_acl_tcam: Sửa lỗi rò rỉ bộ nhớ khi hủy công việc rehash (tái băm)
Công việc trì hoãn rehash sẽ được lên lịch lại với độ trễ nếu số lượng tín dụng (credits) tại thời điểm kết thúc công việc không âm, vì theo giả định ban đầu thì điều này có nghĩa là quá trình di chuyển dữ liệu đã hoàn tất. Ngược lại, nó sẽ được lên lịch lại ngay lập tức.
Sau khi áp dụng bản sửa lỗi "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash" (Sửa lỗi sử dụng sau giải phóng khả thi trong quá trình tái băm), thông tin trên không còn chính xác nữa vì số lượng tín dụng không âm không còn là dấu hiệu cho thấy việc di chuyển dữ liệu đã hoàn tất. Trường hợp này cũng có thể xảy ra nếu công việc gặp phải lỗi, lúc đó quá trình di chuyển sẽ tiếp tục vào lần sau khi công việc được lên lịch lại.
Ý nghĩa của vấn đề trên là công việc có thể ở trạng thái chờ (pending) và liên kết với các gợi ý (hints) đã được cấp phát khi bắt đầu quá trình di chuyển dữ liệu. Điều này dẫn đến việc các gợi ý bị rò rỉ [1] khi công việc bị hủy trong lúc đang chờ, như một phần của quy trình tháo dỡ vùng ACL.
Khắc phục bằng cách giải phóng bộ nhớ cho các gợi ý nếu chúng liên kết với một công việc đã bị hủy trong trạng thái chờ.
Gán trách nhiệm (blame) cho commit gốc vì sự phụ thuộc vào giả định không có công việc nào đang chờ được liên kết với các gợi ý là thiếu vững chắc.
[1]
unreferenced object 0xffff88810e7c3000 (size 256): comm "kworker/0:16", pid 176, jiffies 4295460353 hex dump (first 32 bytes): 00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a....... 00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@........... backtrace (crc 2544ddb9): [] kmalloc_trace+0x23f/0x2a0
[] objagg_hints_get+0x42/0x390
[] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400
[] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160
[] process_one_work+0x59c/0xf20
[] worker_thread+0x799/0x12c0
[] kthread+0x246/0x300
[] ret_from_fork+0x34/0x70
[] ret_from_fork_asm+0x1a/0x30
If you want to get the best quality for vulnerability data then you always have to consider VulDB.