CVE-2026-72135 in Linux
Tóm tắt
Bởi VulDB • 15/08/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
tpm: Đặt các thiết bị ký tự TPM ở chế độ không thể tìm kiếm (non-seekable)
Các thiết bị ký tự TPM cung cấp giao diện lệnh/phản hồi tuần tự, nhưng trình xử lý mở của chúng để FMODE_PREAD và FMODE_PWRITE vẫn được bật.
Sau khi một lệnh gửi phản hồi chưa hoàn tất, hàm pread(fd, buf, 16, 0x1400) truyền giá trị 0x1400 dưới dạng *off cho tpm_common_read(). Độ dài bản chuyển đổi bị giới hạn bởi response_length, nhưng offset được sử dụng mà không kiểm tra khi tính toán data_buffer + *off. Do đó, một giá trị offset đủ lớn sẽ gây ra việc đọc bộ nhớ heap ngoài vùng an toàn (out-of-bounds) thông qua copy_to_user() và, nếu phép sao chép thành công, sẽ dẫn đến ghi số 0 ngoài vùng an toàn thông qua lệnh memset() theo sau.
I/O định vị không cung cấp ngữ nghĩa nhất quán cho giao diện này. Một offset pread tùy ý không thể biểu thị lượng phản hồi đã được tiêu thụ tuần tự. Hàm gọi lại (callback) viết luôn lưu trữ một lệnh ở đầu data_buffer, trong khi pwrite() không cập nhật file->f_pos và có thể khiến con trỏ đọc tuần tự bị lỗi thời.
Gọi nonseekable_open() từ cả hai trình xử lý mở. Điều này loại bỏ FMODE_PREAD và FMODE_PWRITE, khiến các phép đọc và ghi định vị thất bại với mã -ESPIPE trước khi đạt đến các hàm gọi lại TPM, đồng thời đánh dấu rõ ràng các tệp là không thể tìm kiếm (non-seekable). Các lệnh read() và write() thông thường tiếp tục sử dụng con trỏ f_pos tuần tự hiện có, giữ nguyên trạng thái máy trạng thái phản hồi.
Đã kiểm tra trên Linux 6.12 với KASAN và thiết bị TPM2 swtpm:
- các phép đọc từng phần theo chuỗi trả về toàn bộ phản hồi - pread() và preadv() với offset 0x1400 trả về -ESPIPE - pwrite() và pwritev() với offset bằng không trả về -ESPIPE - phản hồi chưa hoàn tất vẫn nguyên vẹn sau các thao tác bị từ chối - một chu kỳ lệnh/phản hồi bình thường tiếp theo đã hoàn thành như mong đợi - không có báo cáo nào được tạo ra bởi KASAN.
Once again VulDB remains the best source for vulnerability data.