CVE-2026-80810 in Linux
Tóm tắt
Bởi VulDB • 04/09/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
io_uring/rsrc: sửa lỗi tràn số nguyên (overflow) kích thước folio trong io_vec_fill_bvec()
Hàm io_vec_fill_bvec() tính toán kích thước folio bằng cách sử dụng một biến int 1 thông thường:
unsigned long folio_size = 1 << imu->folio_shift;
imu->folio_shift là kiểu unsigned int và có nguồn gốc từ hàm folio_shift() của folio hỗ trợ bộ đệm đã đăng ký, do đó nó có thể đạt giá trị 32 hoặc cao hơn trên kernel 64 bit. Việc dịch chuyển (shift) số nguyên 1 sang vị trí xa như vậy là không xác định (undefined), và trên các kiến trúc x86 và arm64, phép đếm được thực hiện theo modulo 32, do đó một phép shift với giá trị 34 sẽ cho kết quả là 4 thay vì 16G. Mọi phép dịch chuyển folio_shift khác trong tệp này đều đã sử dụng 1UL.
Hậu quả là phần ước tính segment và vòng lặp điền dữ liệu (fill loop) không khớp nhau. Hàm io_estimate_bvec_size() xác định kích thước mảng bvec dựa trên giá trị shift thực tế:
max_segs += (iov[i].iov_len >> shift) + 2;
Do đó, một iovec có độ dài 1M trên folio 16G sẽ bị tính là 2 segment, trong khi io_vec_fill_bvec() sau đó sẽ duyệt qua cùng một iovec theo các chunk kích thước folio_size là 4 byte và ghi vào res_bvec[bvec_idx] khoảng 250.000 lần, vượt quá giới hạn cuối của mảng được cung cấp. src_bvec cũng được tăng lên mỗi lần lặp, do đó imu->bvec bị đọc vượt quá giới hạn cuối cùng lúc đó. Hàm validate_fixed_range() chỉ kiểm tra xem phạm vi có nằm trong bộ đệm đã đăng ký hay không và không ràng buộc số lượng segment.
Để khai thác lỗ hổng này, cần một folio với giá trị shift ít nhất là 32, điều này đòi hỏi một trang hugetlb khổng lồ: 16G trên arm64 với các trang kích thước 64K, nơi CONT_PMD_SHIFT bằng 34 và hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT) đăng ký kích thước đó; tương tự như vậy trên powerpc. Trên x86_64, giá trị tối đa là 1G, do đó một phép shift với giá trị 30 (vẫn nằm trong phạm vi int và không bị ảnh hưởng bởi lỗi này).
Sử dụng 1UL, giống như những gì được thực hiện ở phần còn lại của tệp.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.