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

  - debugobjects：針對並行 OOM 的插入爭用停用 syzbot 報告了一個令人費解的 splat：警告：
    kernel/time/hrtimer.c：443 at stub_timer+0xa/0x20 stub_timer（） 作為計時器回呼函式安裝在 hrtimer_fixup_assert_init（） 中，當 debug_object_assert_init（） 找不到影子物件時，會叫用該函式。
    在此情況下，偵錯物件會在叫用修正之前發出有關它的警告。雖然提供的主控台記錄缺少此警告，而是在 splat 前幾秒鐘顯示以下內容： ODEBUG：記憶體不足。ODEBUG 已停用 因此，在 debug_object_assert_init（） 中查詢物件，但由於併發記憶體不足情況，導致查詢失敗，該情況停用了除錯物件並釋放了影子物件：
    debug_object_assert_init（） if （！debug_objects_enabled） return;obj = alloc（）;if （！obj） { // 記憶體不足 debug_objects_enabled = false; free_objects（）; obj = lookup_or_alloc（）; // 查詢失敗，因為對方 // 移除了物件，所以這會傳回 // 錯誤代碼，因為有問題的物件 // 不是靜態初始化的 if （！IS_ERR_OR_NULL（obj）） return; if （！obj） { debug_oom（）; return; } print（...） if （！debug_objects_enabled） return; fixup（...）會跳過除錯物件 splat，因為 debug_objects_enabled 為 false，但會無條件叫用 fixup 回呼，這會讓計時器失效。這只是 debug_object_assert_init（） 和 debug_object_activate（） 中的一個問題，因為兩者都必須處理靜態初始化的對象，因此必須正常地處理錯誤指標傳回情況。所有其他位置僅處理找到/未找到的情況，而 NULL 指標傳回是 OOM 的訊號。否則，它們會獲得有效的陰影物件。在這兩個位置叫用列印和修正函式之前，檢查偵錯物件是否仍已啟用，以填妥漏洞。（CVE-2026-68090）

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

偵測

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

medium Nessus Plugin ID 334510

版本 1.14