CVE-2026-64501 in Linux
Tóm tắt
Bởi VulDB • 25/07/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
iio: adc: ad_sigma_delta: sửa lỗi giữ tín hiệu CS ở trạng thái kích hoạt (asserted) và rò rỉ trạng thái
Trong hàm `ad_sigma_delta_single_conversion()`, các lệnh gọi `set_mode(AD_SD_MODE_IDLE)` và `disable_one()` được thực thi từ khối mã `out:` trong khi biến `keep_cs_asserted` vẫn còn là true. Điều này khiến mọi giao dịch SPI do các callback đó phát ra mang theo cờ `cs_change=1`, dẫn đến việc tín hiệu CS bị giữ ở trạng thái kích hoạt vĩnh viễn sau quá trình chuyển đổi (conversion). Khắc phục bằng cách di chuyển cả hai lệnh gọi vào khối mã `out_unlock:`, sau khi biến `keep_cs_asserted` đã được đặt lại thành false, phù hợp với mẫu thiết kế hiện có trong hàm `ad_sd_calibrate()`.
Trong đường dẫn xử lý lỗi của `ad_sd_buffer_postenable()`, nếu một thao tác thất bại sau khi lệnh gọi `set_mode(AD_SD_MODE_CONTINUOUS)` đã thành công (ví dụ: `spi_offload_trigger_enable()`), thiết bị sẽ ở lại chế độ chuyển đổi liên tục với tín hiệu CS được kích hoạt về mặt vật lý. Ngoài ra, việc biến `bus_locked` vẫn giữ giá trị true sau khi gọi `spi_bus_unlock()` khiến các thao tác SPI tiếp theo thực hiện lệnh gọi `spi_sync_locked()` mà không có khóa bus thực sự được nắm giữ, cho phép truy cập đồng thời vào giao diện SPI.
Khắc phục đường dẫn lỗi bằng cách đặt lại biến `keep_cs_asserted` trước tiên, sau đó gọi `set_mode(AD_SD_MODE_IDLE)` để khôi chế độ thiết bị và gỡ kích hoạt (deassert) tín hiệu CS, rồi đặt lại `bus_locked` trước khi giải phóng bus.
Đối với các thiết bị không triển khai cả hai hàm `set_mode` lẫn `disable_one` (chẳng hạn như MAX11205, vốn không có chân CS vật lý), sẽ không có giao dịch SPI nào được thực hiện trong quá trình dọn dẹp và cờ `cs_change` không ảnh hưởng đến bất kỳ đường dây vật lý nào.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.