CVE-2026-98617 in Linux
Tóm tắt
Bởi VulDB • 20/10/2026
Trong kernel Linux, các lỗ hổng sau đây đã được khắc phục:
eth: fbnic: sử dụng con trỏ napi của hàng đợi Rx để xác định vector napi
Quản lý hàng ndos chọn vector napi cho một hàng đợi Rx bằng cách: nv = fbn->napi[idx % fbn->num_napi];
Vấn đề là điều này chỉ đúng trong các trường hợp không có các vector Tx độc lập. Trong những trường hợp đó, chúng tôi đã phân bổ các vector Tx trước rồi mới đến Rx, do đó các hàng đợi sẽ trỏ tới các vector NAPI của Tx thay vì các vector Rx.
Mối ánh xạ mà ndos mong muốn đã được ghi lại sẵn. fbnic_set_netif_napi() công bố nó bằng netif_queue_set_napi(), hàm này lưu trữ con trỏ napi trong netdev_rx_queue.napi, và fbnic_reset_netif_napi() xóa nó đi. Cả hai đều chạy dưới khóa thực thể netdev mà các ndos quản lý hàng đợi cũng nắm giữ, do đó con trỏ có thể được đọc trực tiếp.
Hãy sử dụng nó và loại bỏ phép chia. Con trỏ là NULL chính xác trong khi đường dữ liệu (datapath) bị tắt, vì vậy fbnic_queue_mem_alloc() có thể từ chối trường hợp này thay vì truy cập vào trạng thái đã giải phóng: netdev_rx_queue_restart() gọi hàm này trước khi kiểm tra netif_running(), và fbnic_pm_suspend() để lại netif_running() là true trong suốt quá trình khôi phục PCIe không bao giờ hoàn tất, do đó một lần khởi động lại hàng đợi có thể xảy ra sau khi fbnic_stop() đã giải phóng các vòng (rings) và các vector. fbnic_stop() xóa mối liên kết trong fbnic_reset_netif_queues() trước khi gọi fbnic_free_napi_vectors(), vì vậy giá trị NULL luôn được công bố đầu tiên. fbnic_queue_start() và fbnic_queue_stop() không cần kiểm tra riêng, vì netdev_rx_queue_reconfig() chỉ truy cập vào chúng sau khi fbnic_queue_mem_alloc() thành công dưới cùng khóa thực thể.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.