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

  - xen/events對應清理後的 evtchn shutdown_pirq 和 startup_pirq 並未採用 irq_mapping_update_lock因為它們因鎖定反轉而無法採用。兩者都是在取得 irq_desc->lock 時呼叫。不過鎖定順序為先 irq_mapping_update_lock再 irq_desc->lock。這會引發多個爭用- shutdown_pirq 可被配置事件通道的函式中斷
    CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> 傳回剛剛釋放的 evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } 此處假設事件通道 e 此處指的是相同的事件通道編號。在此爭用之後e 的 evtchn_to_irq 對應無效 (-1)。 - __startup_pirq 會以類似的方式與 __unbind_from_irq 爭用。因為
    __startup_pirq 不採用 irq_mapping_update_lock其可擷取 __unbind_from_irq 目前正在釋放及清理的 evtchn。在此情況下即使事件通道已配置也可取消在 evtchn_to_irq 中設定的對應。修正方法是先清理對應再關閉事件通道。
    如此可保證在配置事件通道時已取消設定其潛在的先前 evtchn_to_irq 對應。這也是先配置事件通道再設定對應的相反配置順序。在認可 3fcdaf3d7634 (xen/events修改內部的 [un]bind 介面) 之前的 5.10 核心中我們在探查 NVMe 裝置期間遇到類似下列的錯誤。問題在於在 nvme_setup_io_queues 期間系統會針對每個裝置呼叫 pci_free_irq進而導致呼叫 shutdown_pirq。若使用許多 nvme 裝置則可能在開機期間發生此爭用因為會有多個 shutdown_pirq 呼叫且 startup_pirq 可能會平行執行。 ------------[cut here ]------------ blkfront: xvdabarrier or flush:disabled;持續授權啟用間接描述符號啟用彈回緩衝區已啟用位於 drivers/xen/events/events_base.c:499! 的核心錯誤無效 opcode0000 [#1] SMP PTI CPU44 PID375 Comm
    kworker/u257:23 未受污染的 5.10.201-191.748.amzn2.x86_64 #1 硬體名稱Xen HVM domU、BIOS 4.11.amazon 2006 年 8 月 24 日 工作佇列nvme-reset-wq nvme_reset_work RIP0010:bind_evtchn_to_cpu+0xdf/ 0xf0 代碼5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09
     R10ffffffff82d72b00  : 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0 0000000080050033 CR20000000000000000 CR3
    0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ?
    __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0x ---truncated--- (CVE-2024-26687)

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

偵測

Linux Distros 未修補的弱點：CVE-2024-26687

medium Nessus Plugin ID 227896

版本 1.5