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

  - xen/事件映射清理之后关闭 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 映射。这也是分配的逆序，即首先分配事件通道，然后再设置映射。在提交 3fcdaf3d7634xen/events修改内部 [un]bind 接口之前的 5.10 内核中我们在探测 NVMe 设备期间会遇到如下所示的缺陷。问题在于在 nvme_setup_io_queues 期间会为每个设备调用 pci_free_irq导致调用 shutdown_pirq。对于许多 nvme 设备可能会在引导期间遇到此争用因为可能会并行运行 shutdown_pirq 和 startup_pirq 的多个调用。 ------------[ 在此处切换 ]------------ blkfrontxvdabarrier 或 flush禁用持久性授予已启用间接描述符已启用bounce 缓冲区drivers/xen/events/events_base.c:499! 的已启用内核缺陷无效的 opcode0000 [#1] SMP PTI CPU: 44 PID: 375 Comm
    kworker/u257:23 未受感染 5.10.201-191.748.amzn2.x86_64 #1 硬件名称Xen HVM domU、BIOS 4.11.amazon 08/24/2006 工作队列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 CR2: 0000000000000000 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 插件 ID 227896

版本 1.5