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

  - hwrng： core - 使用 RCU 和 work_struct 來修正爭用情形 目前，直到 hwrng_fillfn（） 執行緒結束，才會清除hwrng_fill。由於 hwrng_unregister（） 讀取rng_mutex鎖定之外的hwrng_fill，因此並行 hwrng_unregister（） 可能會在同一任務上再次呼叫 kthread_stop（）。此外，如果在 hwrng_register（） 之後立即呼叫 hwrng_unregister（），則停止的執行緒可能從未被執行過。因此，即使在 hwrng_unregister（） 傳回之後，hwrng_fill 仍會保持髒狀態。在這種情況下，後續對 hwrng_register（） 的呼叫將無法啟動新的執行緒，並且 hwrng_unregister（） 將在同一個釋放的任務上呼叫 kthread_stop（）。在這兩種情況下，都會發生釋放後使用：refcount_t：在 0 上加法;釋放後使用。
    警告：...lib/refcount.c：25 refcount_warn_saturate+0xec/0x1c0 呼叫追蹤：kthread_stop+0x181/0x360 hwrng_unregister+0x288/0x380 virtrng_remove+0xe3/0x200 此修補程式透過保護 rng_mutex 鎖定內的全域 hwrng_fill 指標來修正爭用，因此 hwrng_fillfn（） 執行緒只會停止一次，並且對 kthread_run（） 和 kthread_stop（） 的呼叫會在持有的鎖定的情況下序列化。為了避免 hwrng_fillfn（） 在保持鎖定的情況下停止時出現鎖死，我們將 current_rng 轉換為 RCU，以便 get_current_rng（） 可以在不保持鎖定的情況下讀取current_rng。為了從 put_rng（） 中刪除鎖定，我們還將實際清理延遲到work_struct中。由於 get_current_rng（） 不再傳回ERR_PTR值，因此會從呼叫端移除 IS_ERR（） 檢查。當 hwrng_fill 受到 rng_mutex 鎖定保護時，hwrng_fillfn（） 無法再清除 hwrng_fill 本身。因此，如果 hwrng_fillfn（） 在丟棄current_rng後直接傳回，則稍後會在釋放的task_struct上呼叫 kthread_stop（）。為了解決此問題，hwrng_fillfn（） 現在呼叫 schedule（） 以使任務保持活動狀態，直到停止為止。kthread_stop（） 呼叫也從 hwrng_unregister（） 移至 drop_current_rng（），確保在 current_rng 變為 NULL 的所有可能路徑上呼叫 kthread_stop（），這樣執行緒就不會永遠等待。（CVE-2026-45949）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

偵測

Linux Distros 未修補弱點：CVE-2026-45949

medium Nessus Plugin ID 317183

版本 1.7