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

  - 9p/trans_fd一律使用 O_NONBLOCK 讀取/寫入 syzbot 報告 p9_fd_close() 的 p9_mux_poll_stop() [1]因為 p9_conn_destroy() from p9_fd_close() 的 p9_mux_poll_stop() 無法中斷已啟動的 kernel_read() p9_fd_read() p9_write_work() 要求的 p9_read_work() 和/或 p9_fd_write() 的 kernel_write()。由於 p9_socket_open() 已設定 O_NONBLOCK 旗標因此 p9_mux_poll_stop() 不需要中斷 kernel_read()/kernel_write()。不過由於 p9_fd_open() 並未設定 O_NONBLOCK 旗標而是透過管道封鎖除非訊號擱置因此檔案描述符號參照管道時p9_mux_poll_stop() 需要中斷 kernel_read()/kernel_write()。換句話說管道檔案描述符號必須按照通訊端檔案描述符號處理。我們因故需要中斷管道上的 kernel_read()/kernel_write()。此修補程式的最小變更是從 p9_fd_open() 設定 O_NONBLOCK 旗標因為 O_NONBLOCK 旗標不會影響一般檔案的讀取/寫入。但是此方法會變更使用者空間提供之檔案描述符號上的 O_NONBLOCK 旗標 (可能會中斷使用者空間程式)且 O_NONBLOCK 旗標可由使用者空間變更。每次叫用 p9_fd_read()/p9_fd_write() 時皆可設定 O_NONBLOCK 旗標但仍會保留小爭用視窗用於清除 O_NONBLOCK 旗標。如果不想操控 O_NONBLOCK 旗標可能可以 set_thread_flag(TIF_SIGPENDING) 和 recalc_sigpending() 圍繞 kernel_read()/kernel_write()。由於 p9_read_work()/p9_write_work() 工作是由處理全域 system_wq 工作佇列的核心執行緒所處理因此從 p9_fd_close() 呼叫 p9_conn_destroy() 的 p9_mux_poll_stop() 時無法從遠端執行緒傳送訊號。因此如果我們要依賴訊號讓 kernel_read()/kernel_write() 變成非封鎖則每次都需要呼叫 set_thread_flag(TIF_SIGPENDING)/recalc_sigpending()。[Dominique應Christian 的建議新增註解] (CVE-2022-49767)

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

偵測

Linux Distros 未修補的弱點：CVE-2022-49767

medium Nessus Plugin ID 246821

版本 1.14