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

  - bpf修正同步回呼的參照狀態管理 目前驗證程式會驗證回呼函式 (同步與非同步)就像函式會執行一次一樣 (即它會探索執行狀態就像函式遭到呼叫一次一樣)。下一個要探索的 insn 設為 subprog 的開頭且使用 curframe > 0 和 prepare_func_exit 處理巢狀框架的結束。發生非同步回呼時它會使用 push_stack 的自訂變體模擬一種分支來設定非同步回呼的自訂狀態和執行內容。雖然這種方法很簡單而且在回呼確實只會執行一次時有效但是對於我們目前所有的 for_each 樣式協助程式而言它是不安全的即它們會執行回呼多次。釋放所取得之呼叫者之參照的回呼可能會多次執行此動作但目前驗證器會將其視為框架內的一個呼叫然後傳回給呼叫者。因此它會認為其已釋放某些參照使 cb 例如可透過 callback_ctx (從堆疊上的溢出輸入暫存器填入 cb 內的暫存器) 取得存取權。同樣地它可能會看到取得呼叫在回呼內未配對因此呼叫者將復制回呼的參照狀態然後必須以新的 ref_obj_ids 釋放暫存器。不過回呼可能會執行多次但驗證器只會針對回呼的單一符號執行考慮取得的參照而這會造成洩漏。請注意非同步回呼情況有所不同。雖然目前 bpf_timer_set_callback 只會執行一次但即使對於多次執行它也是安全的因為參照狀態為 NULL而且 check_reference_leak 會強製程式在 BPF_EXIT 之前釋放狀態。此狀態也不會受到呼叫者框架分析的影響。因此非同步回呼是安全的。由於我們希望參照狀態可供存取 (例如透過 callback_ctx 的 PTR_TO_STACK 從堆疊載入的指標)因此我們仍然必須將呼叫者的reference_state 複製到 callback 的 bpf_func_state但我們會強制其新增至該reference_state 的所有參照皆已在其命中 BPF_EXIT 之前釋放。這需要在參照狀態中引入新的 callback_ref 成員以區分呼叫者和被呼叫者參照。因此如果 check_reference_leak 發現我們在 callback_fn 中而且我們尚未釋放 callback_ref refs現在會出錯。由於可能有多個巢狀回呼例如 frame 0 -> cb1 -> cb2 等等。
    我們也需要辨別此特定參照是屬於此回呼框架還是父項以及僅屬於我們自己的錯誤因此我們儲存了 state->frameno (對於回呼其一律為非零)。簡而言之回呼可以讀取父項reference_state但無法加以變動以便能夠使用呼叫者取得的指標。必須在傳回之前於呼叫者reference_state 上復原變更 (透過在 BPF_EXIT 之前釋出自己的 acquire_refs)然後再傳回 (此時呼叫者和回呼狀態將以任何方式符合因此不需要將其複制回呼叫者)。 (CVE-2022-50650)

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

偵測

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

high Nessus Plugin ID 278044

版本 1.14