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

  - futex：在重新排隊 PI 期間防止 rcuwait 釋放後使用 在 PREEMPT_RT 上，FUTEX_CMP_REQUEUE_PI可以在 futex_requeue_pi_complete（） 叫用 rcuwait_wake_up（） 時觸發 KASAN 報告 （slab-out-of-bounds）。futex_wait_requeue_pi（） 使用的futex_q分配在服務員的堆疊上。提前喚醒可以與 PI 重新排隊競爭，如下所示： 服務員重新排隊任務 ------ ------------ futex_wait_requeue_pi（） futex_do_wait（） schedule（） futex_requeue futex_proxy_trylock_atomic（） futex_requeue_pi_prepare（） Q_REQUEUE_PI_NONE -> Q_REQUEUE_PI_IN_PROGRESS * timeout/ signal 喚醒服務員 * futex_requeue_pi_wakeup_sync（） Q_REQUEUE_PI_IN_PROGRESS -> Q_REQUEUE_PI_WAIT requeue_pi_wake_futex futex_requeue_pi_complete（） cmpxchg Q_REQUEUE_PI_WAIT -> Q_REQUEUE_PI_LOCKED rcuwait_wait_event（） if （atomic_read（&q->requeue_state） ！= Q_REQUEUE_PI_WAIT） break /* 無 schedule（） */ /* q.pi_state->owner == current */ futex_private_hash_put（） /* 來自 syscall 的傳回 */ rcuwait_wake_up（&q->requeue_wait） /* q 已消失 */ futex_requeue_pi_complete（） 在呼叫 rcuwait_wake_up（） 之前發布Q_REQUEUE_PI_LOCKED。服務員在叫用 rcuwait_wait_event（） 中的 schedule（） 之前，會在 rcuwait_wait_event（） 中觀察此狀態。在這裡，服務員可以騰出離開系統調用，然後重新排隊任務才能完成喚醒。若要解決此爭用，請跳過Q_REQUEUE_PI_LOCKED情況下的 rcuwait_wake_up（）。此狀態僅由 requeue_pi_wake_futex（） 發布，它在 futex_requeue_pi_complete（） 之前儲存 q->task，並透過 wake_up_state（） 喚醒服務員。此喚醒旨在將服務員從 futex_do_wait（） 睡眠中喚醒。如果服務員仍然睡在那裡，它就無法進入Q_REQUEUE_PI_WAIT狀態（並且需要刪除喚醒）。如果服務員透過其他方式從 futex_do_wait（） 喚醒（如本例所示）並在 futex_requeue_pi_wakeup_sync（） 中睡覺，那麼 requeue_pi_wake_futex（） 中的 wake_up_state（） 也會喚醒它。如果服務員任務在 wake_up_state（） 有機會喚醒任務之前終止，則任務指標不會失效，因為 futex_hash_bucket：：lock 被保留並且任務指標受到 RCU 保護。[bigeasy：更新了註解和提交訊息]（CVE-2026-90003）

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

偵測

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

high Nessus Plugin ID 346483

版本 1.18