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

  - eventpoll：修正ep_remove結構 eventpoll / 結構檔案 UAF ep_remove（） （透過 ep_remove_file（）） 清除 file->f_lock 下的 file->f_ep，但隨後繼續在關鍵區段內使用 @file （is_file_epoll（），hlist_del_rcu（） 通過頭部，spin_unlock）。在該視窗中採用 eventpoll_release（） 快速路徑的並行 __fput（） 觀察到暫時性 NULL，跳過 eventpoll_release_file（） 並執行至 f_op->release / file_free（）。對於 epoll-watches-epoll 案例，f_op->release 是 ep_eventpoll_release（） -> ep_clear_and_put（） -> ep_free（），其中 kfree（） 會監視結構 eventpoll。它嵌入的 ->refs hlist_head正是 epi->fllink.pprev 指向的位置，因此後續的 hlist_del_rcu（） 的 *pprev = next 會潦草地寫到釋放的 kmalloc-192 記憶體中。此外，結構檔案是SLAB_TYPESAFE_BY_RCU的，因此插槽備份@file可以由 alloc_empty_file（） 回收 -- 重新初始化 f_lock 和 f_ep -- 而 ep_remove（） 名義上仍位於該鎖內。結果是攻擊者可控制的針對錯誤的 slab 快取的 kmem_cache_free（）。透過 ep_remove（） 頂部的 epi_fget（） 引腳@file，並閘極成功引腳上的關鍵部分。保留引腳時，@file無法達到參照計數零，這會使 __fput（） 關閉並轉移地使受監視的結構 eventpoll 在 hlist_del_rcu（） 和 f_lock 使用中保持活動狀態，從而關閉兩個 UAF。如果引腳發生故障，@file已經達到參照計數零，並且其 __fput（） 正在飛行中。因為我們在清除f_ep之前就放棄了，所以該路徑採用 eventpoll_release（） 慢速路徑進入 eventpoll_release_file（），並在 ep->mtx 上阻塞，直到服務員端的 ep_clear_and_put（） 刪除它。保釋的 epi 在 ep->refcount 中的份額保持不變，因此 ep_clear_and_put（） 中的尾端 ep_refcount_dec_and_test（） 無法將 eventpoll 從 eventpoll_release_file（） 下釋放出來;然後，孤立的 EPI 會在那裡被清理。成功的 pin 也證明我們沒有在這個 epi 上進行 eventpoll_release_file（） 的比賽，所以放棄現在多餘的 epi->dying under f_lock 的重新檢查。廉價的無鎖READ_ONCE（epi->垂死）快速救助仍然存在。（CVE-2026-46242）

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

偵測

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

high Nessus Plugin ID 318062

版本 1.17