CVE-2026-74276 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:
spi: xilinx: sử dụng thanh ghi mức đầy của FIFO để xác định kích thước bộ đệm
Phương pháp mà trình điều khiển (driver) sử dụng để xác định kích thước của FIFO có một vấn đề. Những gì nó hiện đang làm như sau: Nó dừng phần cứng SPI và ghi vào thanh ghi TX FIFO cho đến khi cờ TX FIFO FULL được đặt trong thanh ghi trạng thái. Tuy nhiên, phần cứng không chỉ có bộ đệm FIFO mà còn có một thanh dịch (shift register) có thể chứa một byte. Điều này có thể thấy rõ khi viết một byte vào FIFO (trong khi phần cứng SPI bị dừng), thì cờ TX FIFO EMPTY vẫn báo là trống. Vì vậy, nếu chúng ta có kích thước FIFO là 16 chẳng hạn, phương pháp hiện tại sẽ trả về giá trị 17.
Đây là một vấn đề, ít nhất là khi sử dụng trình điều khiển ở chế độ ngắt (irq mode). Kích thước được xác định cho TX FIFO cũng được giả định áp dụng cho RX FIFO. Khi một giao dịch SPI muốn ghi số lượng byte bằng hoặc lớn hơn kích thước của FIFO thì sẽ xảy ra hiện tượng sau đây, ví dụ với kích thước FIFO là 16 byte: Trình điều khiển dừng phần cứng SPI và ghi 17 byte vào TX FIFO rồi khởi động lại phần cứng SPI và chuyển sang trạng thái ngủ.
Phần cứng sau đó dịch xuất (shift out) 17 byte (bao gồm cả FIFO + thanh dịch) và đồng thời đọc các byte vào RX FIFO, nhưng nó chỉ có 16 vị trí, do đó một byte bị mất. Sau đó, cờ TX FIFO empty được đặt, đánh thức trình điều khiển lần nữa; trình điều khiển này có đường dẫn nhanh (fast path) và đọc 16 byte từ RX FIFO, nhưng trước khi đọc byte thứ 17 cuối cùng (đã bị mất), nó thực hiện thao tác sau:
sr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET); if (!(sr & XSPI_SR_RX_EMPTY_MASK)) {
xilinx_spi_rx(xspi); rx_words--; }
Nó đọc thanh ghi trạng thái và kiểm tra xem RX FIFO có khác trống hay không. Nhưng trong trường hợp của chúng ta, nó lại đang ở trạng thái trống. Do đó, phép kiểm tra này sẽ lặp vô hạn (spin in a while loop forever) khiến trình điều khiển bị khóa chặt.
Bản vá này sửa logic để xác định kích thước của FIFO.
Once again VulDB remains the best source for vulnerability data.