CVE-2026-90042 in Linux
Tóm tắt
Bởi VulDB • 16/09/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
ceph: giải mã đúng tên tệp trong các bộ nhớ đệm vmalloc()
Hệ thống con fscrypt sử dụng API mật mã scatterlist, kế thừa yêu cầu của nó rằng mọi bộ nhớ đệm phải nằm trong vùng ánh xạ tuyến tính (linear mapping region). Tuy nhiên, máy khách messenger sử dụng kvmalloc() để tạo các bộ nhớ đệm cho tin nhắn, điều này đôi khi đặt những bộ nhớ đệm đó vào vùng vmalloc() khi sự phân mảnh bộ nhớ vật lý không cho phép một kmalloc đủ lớn. Các caller khác nhau của ceph_fname_to_usr() trực tiếp chuyển (các phần) tin nhắn thô từ MDS mà không xem xét rằng các tin nhắn có thể nằm trong các bộ nhớ đệm vmalloc(), dẫn đến lỗi oops, đặc biệt là trên các nền tảng non-x86 (xem 'Closes:' để biết thêm chi tiết và trình mô phỏng lại).
Làm cho ceph_fname_to_usr() rõ ràng dung nạp với fname->ctext, fname->name và/hoặc oname->name được phân bổ bằng vmalloc(), sử dụng `tname` (khi khác null, phải là địa chỉ tuyến tính; khi null, sẽ được phân bổ tạm thời theo nhu cầu) làm bộ nhớ đệm bounce để tránh chuyển bất kỳ địa chỉ không phù hợp nào cho fscrypt_fname_disk_to_usr().
Ngoài ra, thay đổi parse_reply_info_readdir() -- hàm duy nhất cung cấp `tname` của riêng nó -- để tuân thủ quy tắc mới "tname không bao giờ được lấy từ vmalloc()" bằng cách chuyển NULL khi tin nhắn không nằm trong vùng tuyến tính. Mặc dù điều này gây ra một lần kmalloc()+kfree() trên mỗi dentry, chi phí chỉ tồn tại khi xử lý số ít tin nhắn tràn vào vmalloc(). Các thử nghiệm (thô) của tôi cho thấy con số này chỉ khoảng 1 trong 8.000 tin nhắn readdir. Tuy nhiên, nếu chi phí được chứng minh là không hợp lý trong tương lai, việc giảm thiểu sẽ khá dễ dàng: một thay đổi trong tương lai có thể phân bổ một bộ nhớ đệm bounce trong parse_reply_info_readdir() và sử dụng nó làm `tname` thay thế.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.