Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - drm/i915/gt：仅当 ACTIVE 为 true 时取消屏蔽中断 intel_rps_boost（） 读取过时的 ACTIVE 状态与排队 rps->work 之间存在较小的争用时段，其中 ACTIVE 可通过 wakeref 终止触发的异步调用进行更改。这意味着 rps_work（） 可在 GT 停止后触发，因此无需保持 PM 唤醒锁定即可取消屏蔽 RPS PM 中断。在 live_rc6_ctx_wa（） 自我测试期间可观察到以下事件序列：1） live_rc6_ctx_wa（） -> intel_engine_pm_put（） -> wakeref_put（） ASYNC1） wakeref_put（） 回调 -> __engine_park（） -> intel_gt_pm_put_async（） -> intel_gt_pm_put_async_untracked（） -> intel_wakeref_put_async（） wakeref_put_async（） 回调 ->
    __gt_park（） -> intel_rps_park（） -> intel_rps_clear_active（） [清除活动] 有中断：-> rps_disable_interrupts（） -> cancel_work_sync（rps->work） -> rps_reset_interrupts（） [rps->pm_iir = 0] 无中断（定时器模式）：-> rps_stop_timer（） -> cancel_work_sync（rps->work） 2） live_rc6_ctx_wa（）
    -> intel_gt_wait_for_idle（） -> intel_gt_retire_requests_timeout（） -> dma_fence_wait_timeout（） -> ops->wait（） [i915_fence_wait（）] -> i915_request_wait_timeout（） -> intel_rps_boost（） -> intel_rps_is_active（） [检查活动] [打开争用窗口] -> queue_work（rps->work） -> retire_requests（） -> i915_request_retire（） -> intel_rps_dec_waiters（） [从 1 到 0] 如果 ASYNC1 和 ASYNC2 在 [打开争用窗口] 期间执行， 然后：3） rps_work（） 从工作队列执行并可能满足 （！pm_iir &&; ！client_boost） 测试（在 TIMER 模式下，rps->pm_iir被较早的 rps_work（） 调用归零或在之前的 intel_rps_unpark（） 事件后永远不会获得新值），因此它跳到标签，绕过 intel_rps_is_active（） 保护并执行 gen6_gt_pm_unmask_irq（）;4） GT 已搁置且运行时 PM 唤醒锁已终止，因此 __gt_park（） -> intel_display_power_put_async（） 中只有原始引用保留 100 毫秒，然后 gen6_gt_pm_unmask_irq（） 中的 MMIO 写入会通过 assert_rpm_wakelock_held（） 检测缺少的唤醒锁定，并发出在硬件访问污染内核期间未保留的 RPM 唤醒锁定 ref。提交 3e7abf814193（drm/i915：
    提取 GT 渲染电源状态管理） 删除了 gen6_pm_rps_work（） 在 i915_irq.c 中对此取消掩码所具有的 if （rps->interrupts_enabled） 防护。INTEL_RPS_ACTIVE将同一个窗口放在括号中，因为它是在 rps_enable_interrupts（） 和 rps_start_timer（） 之前的 intel_rps_unpark（） 中设置的，并且在 rps_stop_timer（） 和 rps_disable_interrupts（） 之前的 intel_rps_park（） 中清除。RPS 不再活动时跳过取消掩码（达到取消掩码操作与中断模式无关）。这不会阻止 RPS 操作在下次取消泊车时恢复。在中断模式下，intel_rps_unpark（） 会调用 rps_enable_interrupts（），启用和取消屏蔽 PM 中断。在定时器模式下，它调用 rps_start_timer（），重新启动定期引擎忙碌度评估。计时器生成软件 RPS 事件，并直接为 rps_work（） 排队，独立于 PM 中断传递。这两种模式都不要求后期工作进程在 GT 停放时取消屏蔽中断（从提交 ca4a6deadad15b91ee083afe445fa6bdbfb68206 中精选出的内容）（CVE-2026-99005）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

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

  - drm/i915/gt：僅當 ACTIVE 為 true 時才解除遮罩中斷 intel_rps_boost（） 讀取過時的 ACTIVE 狀態和將 rps->work 排入佇列之間有一個小的爭用窗口，其中 ACTIVE 可能會透過由 wakeref drop 觸發的非同步呼叫來變更。這表示 rps_work（） 可以在 GT 駐留後觸發，因此可以在不保留 PM 喚醒鎖定的情況下解除遮罩 RPS PM 中斷。在 live_rc6_ctx_wa（） 自我測試期間可能會觀察到以下事件序列： 1） live_rc6_ctx_wa（） -> intel_engine_pm_put（） -> wakeref_put（） ASYNC1） wakeref_put（） 回呼 -> __engine_park（） -> intel_gt_pm_put_async（） -> intel_gt_pm_put_async_untracked（） -> intel_wakeref_put_async（） ASYNC2） wakeref_put_async（） 回呼 ->
    __gt_park（） -> intel_rps_park（） -> intel_rps_clear_active（） [清除 ACTIVE] 有中斷： -> rps_disable_interrupts（） -> cancel_work_sync（rps->work） -> rps_reset_interrupts（） [rps->pm_iir = 0] 無中斷 （計時器模式）： -> rps_stop_timer（） -> cancel_work_sync（rps->work） 2） live_rc6_ctx_wa（）
    -> intel_gt_wait_for_idle（） -> intel_gt_retire_requests_timeout（） -> dma_fence_wait_timeout（） -> ops->wait（） [i915_fence_wait（）] -> i915_request_wait_timeout（） -> intel_rps_boost（） -> intel_rps_is_active（） [檢查 ACTIVE] [OPEN RACE WINDOW] -> queue_work（rps->work） -> retire_requests（） -> i915_request_retire（） -> intel_rps_dec_waiters（） [從 1 到 0] 如果 ASYNC1 和 ASYNC2 將在 [OPEN RACE WINDOW] 期間執行， 然後： 3） rps_work（） 從工作佇列執行，並可能滿足 （！pm_iir &&; ！client_boost） 測試（在 TIMER 模式下，rps->pm_iir 被先前的 rps_work（） 呼叫歸零，或者在之前的 intel_rps_unpark（） 事件之後永遠不會獲得新值），因此它跳到輸出標籤，繞過 intel_rps_is_active（） 保護並執行 gen6_gt_pm_unmask_irq（）;4） GT 被停放並且運行時間 PM 喚醒鎖被刪除，因此只有 __gt_park（） -> intel_display_power_put_async（） 中的原始引用保留 100 毫秒，然後 gen6_gt_pm_unmask_irq（） 中的 MMIO 寫入會透過 assert_rpm_wakelock_held（） 偵測缺少的喚醒鎖，並發出在硬體存取污染核心期間未保留的 RPM 喚醒鎖定參考。提交 3e7abf814193 （drm/i915：
    擷取 GT 渲染電源狀態管理） 刪除了 gen6_pm_rps_work（） 在 i915_irq.c 中圍繞此取消遮罩的 if （rps->interrupts_enabled） 保護。INTEL_RPS_ACTIVE將同一個視窗括起來，因為它是在 rps_enable_interrupts（） 和 rps_start_timer（） 之前的 intel_rps_unpark（） 中設定的，並在 rps_stop_timer（） 和 rps_disable_interrupts（） 之前的 intel_rps_park（） 中清除。當 RPS 不再處於作用中狀態時，跳過取消遮罩 （達到取消遮罩作業與 INTERRUPT 模式無關）。這不會阻止 RPS 作業在下次取消駐留時繼續。在中斷模式下，intel_rps_unpark（） 會呼叫 rps_enable_interrupts（），以啟用和解除遮罩 PM 中斷。在計時器模式下，它會呼叫 rps_start_timer（），重新啟動定期的引擎忙碌度評估。計時器直接產生軟體 RPS 事件並排入佇列 rps_work（），與 PM 中斷傳遞無關。這兩種模式都不需要遲到的工作者在 GT 駐留時解除遮罩中斷 （從提交 ca4a6deadad15b91ee083afe445fa6bdbfb68206 中挑選） （CVE-2026-99005）

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

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - drm/i915/gt;:ACTIVE が true の場合のみ割り込みのマスクを解除します intel_rps_boost() が古い ACTIVE 状態を読み取ることと、rps->work をキューに入れることの間には、小さな競合ウィンドウがあります。ここで、ACTIVE は、wakeref ドロップによってトリガーされる非同期呼び出しを介して変更される可能性があります。これは、GT がパークされた後に rps_work() をトリガーする可能性があることを意味し、PM ウェイクロックを保持せずに RPS PM 割り込みのマスク解除が行われます。この一連のイベントは、live_rc6_ctx_wa() セルフテスト中に観察される場合があります:1) live_rc6_ctx_wa() -> intel_engine_pm_put() -> wakeref_put() ASYNC1) wakeref_put() コールバック -> __engine_park() -> intel_gt_pm_put_async() -> intel_gt_pm_put_async_untracked() -> intel_wakeref_put_async() ASYNC2) wakeref_put_async() コールバック ->
    __gt_park() -> intel_rps_park() -> intel_rps_clear_active() [CLEAR ACTIVE] 割り込みあり: -> rps_disable_interrupts() -> cancel_work_sync(rps->work) -> rps_reset_interrupts() [rps->pm_iir = 0] 割り込みなし(タイマーモード): -> rps_stop_timer() -> cancel_work_sync(rps->work) 2) live_rc6_ctx_wa()
    -> intel_gt_wait_for_idle() -> intel_gt_retire_requests_timeout() -> dma_fence_wait_timeout() -> ops->wait() [i915_fence_wait()] -> i915_request_wait_timeout() -> intel_rps_boost() -> intel_rps_is_active() [アクティブをチェック] [OPEN RACE WINDOW] -> queue_work(rps->work) -> retire_requests() -> i915_request_retire() -> intel_rps_dec_waiters() [from 1 to 0] ASYNC1 および ASYNC2 が [OPEN RACE WINDOW] 中に実行する場合、 その後:3)rps_work()がワークキューから実行され、(!pm_iir &; !client_boost)テスト(TIMERモードで、rps->pm_iirは以前のrps_work()呼び出しでゼロ化されるか、以前のintel_rps_unpark()イベントの後、新しい値を取得することがない)ため、ラベル外にジャンプし、intel_rps_is_active()ガードをバイパスしてgen6_gt_pm_unmask_irq()を実行します。4) GT がパークされ、ランタイム PM ウェイクロックがドロップされます。このため、__gt_park() -> intel_display_power_put_async() の生の参照だけが 100 ミリ秒残ります。その後、gen6_gt_pm_unmask_irq() の MMIO 書き込みは、欠落したウェイクロックを assert_rpm_wakelock_held() を介して検出し、カーネルを汚染する HW アクセス中に保持されない RPM ウェイクロック ref を放出します。コミット 3e7abf814193(drm/i915:
    Extract GT render power state management)は、gen6_pm_rps_work() が i915_irq.c のこのマスク解除に関して持っていた if(rps->interrupts_enabled)ガードをドロップしました。INTEL_RPS_ACTIVE は、rps_enable_interrupts() と rps_start_timer() の前の intel_rps_unpark() で設定され、rps_stop_timer() と rps_disable_interrupts() の前の intel_rps_park() でクリアされているため、同じウィンドウを括弧で囲みます。RPS がアクティブでなくなったらマスク解除をスキップします(マスク解除操作への到達は、INTERRUPT モードとは無関係です)。これは、次回のパーク解除時に RPS 操作が再開することを妨げるものではありません。割り込みモードでは、intel_rps_unpark() が rps_enable_interrupts() を呼び出して、PM 割り込みを有効およびマスク解除します。タイマーモードでは、rps_start_timer() を呼び出し、定期的なエンジンビジー度評価を再起動します。タイマーは、PM 割り込み配信とは無関係に、ソフトウェア RPS イベントを生成し、rps_work() を直接キューに入れます。いずれのモードも、GT の駐車中に、遅刻したワーカーが割り込みのマスクを解除する必要はありません(コミット ca4a6deadad15b91ee083afe445fa6bdbfb68206 からのチェリーピッキング)(CVE-2026-99005)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - drm/i915/gt: Unmask interrupts only when ACTIVE is true There is a small race window between     intel_rps_boost() reading a stale ACTIVE state and queuing rps->work, where ACTIVE may be changed via     asynchronous calls triggered by wakeref drop. This means that rps_work() could be triggered after the GT     has been parked, so unmasking RPS PM interrupts would happen without holding PM wakelock. This sequence of     events may be observed during live_rc6_ctx_wa() selftest: 1) live_rc6_ctx_wa() -> intel_engine_pm_put() ->     wakeref_put() ASYNC1) wakeref_put() callback -> __engine_park() -> intel_gt_pm_put_async() ->     intel_gt_pm_put_async_untracked() -> intel_wakeref_put_async() ASYNC2) wakeref_put_async() callback ->
    __gt_park() -> intel_rps_park() -> intel_rps_clear_active() [clear ACTIVE] WITH INTERRUPTS: ->     rps_disable_interrupts() -> cancel_work_sync(rps->work) -> rps_reset_interrupts() [rps->pm_iir = 0]     WITHOUT INTERRUPTS (TIMER mode): -> rps_stop_timer() -> cancel_work_sync(rps->work) 2) live_rc6_ctx_wa()
    -> intel_gt_wait_for_idle() -> intel_gt_retire_requests_timeout() -> dma_fence_wait_timeout() ->     ops->wait() [i915_fence_wait()] -> i915_request_wait_timeout() -> intel_rps_boost() ->     intel_rps_is_active() [check ACTIVE] [OPEN RACE WINDOW] -> queue_work(rps->work) -> retire_requests() ->     i915_request_retire() -> intel_rps_dec_waiters() [from 1 to 0] If ASYNC1 and ASYNC2 would execute during     [OPEN RACE WINDOW], then: 3) rps_work() executes from the workqueue and may satisfy (!pm_iir &&     !client_boost) test (in TIMER mode rps->pm_iir is zeroed by an earlier rps_work() call or never gets a     new value after previous intel_rps_unpark() event), so it jumps to out label, bypassing     intel_rps_is_active() guard and executes gen6_gt_pm_unmask_irq(); 4) GT is parked and runtime PM wakelock     is dropped, so only a raw reference in __gt_park() -> intel_display_power_put_async() remains for 100ms,     then the MMIO write in gen6_gt_pm_unmask_irq() detects missing wakelock via assert_rpm_wakelock_held() and     emits RPM wakelock ref not held during HW access tainting kernel. Commit 3e7abf814193 (drm/i915:
    Extract GT render power state management) dropped the if (rps->interrupts_enabled) guard that     gen6_pm_rps_work() had around this unmask in i915_irq.c. INTEL_RPS_ACTIVE brackets the same window, since     it is set in intel_rps_unpark() before rps_enable_interrupts() and rps_start_timer() and cleared in     intel_rps_park() before rps_stop_timer() and rps_disable_interrupts(). Skip unmasking when RPS is no     longer active (reaching unmask operation is independent of INTERRUPT mode). This does not prevent RPS     operation from resuming on the next unpark. In interrupt mode, intel_rps_unpark() calls     rps_enable_interrupts(), which enables and unmasks the PM interrupts. In timer mode, it calls     rps_start_timer(), restarting periodic engine-busyness evaluation. The timer generates software RPS events     and queues rps_work() directly, independently of PM interrupt delivery. Neither mode requires the late     worker to unmask interrupts while the GT is parked (cherry picked from commit     ca4a6deadad15b91ee083afe445fa6bdbfb68206) (CVE-2026-99005)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
371487	Linux Distros 未修补的漏洞：CVE-2026-99005	Nessus	Misc.	10/23/2026	10/23/2026	critical
371487	Linux Distros 未修補弱點：CVE-2026-99005	Nessus	Misc.	10/23/2026	10/23/2026	critical
371487	Linux Distros のパッチ未適用の脆弱性: CVE-2026-99005	Nessus	Misc.	10/23/2026	10/23/2026	critical
371487	Linux Distros Unpatched Vulnerability : CVE-2026-99005	Nessus	Misc.	10/23/2026	10/23/2026	critical

Detections

Analytics

Plugins Search

critical

critical

critical

critical