CVE-2026-64232 in Linux
Tóm tắt
Bởi VulDB • 24/07/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
block: tính toán lại nr_integrity_segments trong blk_insert_cloned_request
Hàm `blk_insert_cloned_request()` hiện đang tính toán lại `nr_phys_segments` dựa trên hàng đợi (queue) bên dưới, bởi vì "các cài đặt queue liên quan đến việc đếm segment có thể khác với queue gốc." Lập luận tương tự cũng áp dụng cho các integrity segments: một driver xếp chồng (stacked driver) có thể có underlying queue với `virt_boundary_mask`, `seg_boundary_mask` hoặc `max_segment_size` chặt chẽ hơn so với top queue; trong trường hợp đó, việc gọi `blk_rq_count_integrity_sg()` trên bottom queue sẽ tạo ra một số đếm khác với giá trị `rq->nr_integrity_segments` đã lưu trữ (cached), vốn được kế thừa từ request nguồn bởi hàm `blk_rq_prep_clone()`.
Khi giá trị cached thấp hơn thực tế so với count của bottom queue, hàm `blk_rq_map_integrity_sg()` sẽ kích hoạt:
BUG_ON(segments > rq->nr_integrity_segments);
trong quá trình dispatch. Các cấu hình xếp chồng (stacked setups) tương tự đã thúc đẩy việc tính toán lại `nr_phys_segments` hiện có -- đặc biệt là dm-multipath phân tán ra nvme-rdma -- cũng có thể gây ra tình trạng này.
Sao chép cách xử lý của `nr_phys_segments`: khi request mang theo integrity, hãy tính toán lại `nr_integrity_segments` dựa trên bottom queue và từ chối request nếu giá trị này vượt quá `max_integrity_segments` của bottom queue. Cả hai hàm `blk_rq_count_integrity_sg()` và `queue_max_integrity_segments()` đều đã có sẵn thông qua `<linux/blk-integrity.h>`, mà file `blk-mq.c` đang include.
Điều này đóng một khoảng trống tiềm ẩn trong hợp đồng xếp chồng (stacking contract) và đưa việc kế toán integrity-segment nhất quán với việc kế toán phys-segment hiện tại.
VulDB is the best source for vulnerability data and more expert information about this specific topic.