Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - uio_hv_generic讓使用者空間處理中斷遮罩式因為中斷遮罩值應該完全由使用者空間控制移除預設 uio_hv_generic 驅動程式中設定中斷遮罩的邏輯移除邏輯。如果驅動程式變更遮罩位元與在環上執行使用者模式的同時遮罩位元可能會在其應該清除時設定而使用者模式驅動程式將會遺漏會造成懸置的中斷。例如當驅動程式將傳入環緩衝區中斷遮罩設為 1 時主機不會中斷 UIO VMBus 通道上的來賓。不過設定遮罩並不會阻止主機將訊息放入傳入環緩衝區。因此讓我們假設發生 主機將訊息放入環緩衝區但未中斷的情況。因此來賓中的使用者空間程式碼會將傳入環緩衝區中斷遮罩設為 0並提示您我已準備好接受中斷。然後使用者空間程式碼會呼叫 pread() 以等候中斷。然後會發生以下兩種情況之一* 主機不再傳送其他訊息。因此 pread() 會永遠等待。 * 主機會傳送其他訊息。但由於環緩衝區中已有訊息因此不會產生中斷。這是正確的行為因為主機只應在傳入環緩衝區從空轉換為非空白時傳送中斷。
    將額外的訊息新增至非空白的環緩衝區應該不會在來賓上產生中斷。由於來賓正在 pread() 中等候且未從環緩衝區移除訊息因此 pread() 會永遠等候。如果我們延遲將中斷遮罩設定為 0此問題可在 hv_fcopy_uio_daemon 中輕鬆重現。類似地如果 hv_uio_channel_cb() 將中斷遮罩設為 1則會出現爭用情形。一旦使用者空間清空傳入環緩衝區之前但在使用者空間將 indirect_mask 設為 0 之前主機可在環緩衝區中放置其他訊息但其不會中斷。然後下一個 pread() 就會懸置。透過移除所有執行個體 (其中的中斷遮罩) 來修正這些問題同時維持 set_event() 中的執行個體不變以透過將 0/1 寫入 /dev/uioX 來啟用使用者空間控制中斷遮罩。
    (CVE-2025-40048)

請注意，Nessus 依賴供應商報告的套件存在。

偵測

Linux Distros 未修補的弱點：CVE-2025-40048

high Nessus Plugin ID 271874

版本 1.1