CVE-2024-26687

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/events: close evtchn after mapping cleanup<br /> <br /> shutdown_pirq and startup_pirq are not taking the<br /> irq_mapping_update_lock because they can&amp;#39;t due to lock inversion. Both<br /> are called with the irq_desc-&gt;lock being taking. The lock order,<br /> however, is first irq_mapping_update_lock and then irq_desc-&gt;lock.<br /> <br /> This opens multiple races:<br /> - shutdown_pirq can be interrupted by a function that allocates an event<br /> channel:<br /> <br /> CPU0 CPU1<br /> shutdown_pirq {<br /> xen_evtchn_close(e)<br /> __startup_pirq {<br /> EVTCHNOP_bind_pirq<br /> -&gt; returns just freed evtchn e<br /> set_evtchn_to_irq(e, irq)<br /> }<br /> xen_irq_info_cleanup() {<br /> set_evtchn_to_irq(e, -1)<br /> }<br /> }<br /> <br /> Assume here event channel e refers here to the same event channel<br /> number.<br /> After this race the evtchn_to_irq mapping for e is invalid (-1).<br /> <br /> - __startup_pirq races with __unbind_from_irq in a similar way. Because<br /> __startup_pirq doesn&amp;#39;t take irq_mapping_update_lock it can grab the<br /> evtchn that __unbind_from_irq is currently freeing and cleaning up. In<br /> this case even though the event channel is allocated, its mapping can<br /> be unset in evtchn_to_irq.<br /> <br /> The fix is to first cleanup the mappings and then close the event<br /> channel. In this way, when an event channel gets allocated it&amp;#39;s<br /> potential previous evtchn_to_irq mappings are guaranteed to be unset already.<br /> This is also the reverse order of the allocation where first the event<br /> channel is allocated and then the mappings are setup.<br /> <br /> On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal<br /> [un]bind interfaces"), we hit a BUG like the following during probing of NVMe<br /> devices. The issue is that during nvme_setup_io_queues, pci_free_irq<br /> is called for every device which results in a call to shutdown_pirq.<br /> With many nvme devices it&amp;#39;s therefore likely to hit this race during<br /> boot because there will be multiple calls to shutdown_pirq and<br /> startup_pirq are running potentially in parallel.<br /> <br /> ------------[ cut here ]------------<br /> blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled<br /> kernel BUG at drivers/xen/events/events_base.c:499!<br /> invalid opcode: 0000 [#1] SMP PTI<br /> CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1<br /> Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006<br /> Workqueue: nvme-reset-wq nvme_reset_work<br /> RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0<br /> Code: 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 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00<br /> RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006<br /> RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff<br /> RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed<br /> R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002<br /> FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> ? show_trace_log_lvl+0x1c1/0x2d9<br /> ? show_trace_log_lvl+0x1c1/0x2d9<br /> ? set_affinity_irq+0xdc/0x1c0<br /> ? __die_body.cold+0x8/0xd<br /> ? die+0x2b/0x50<br /> ? do_trap+0x90/0x110<br /> ? bind_evtchn_to_cpu+0xdf/0xf0<br /> ? do_error_trap+0x65/0x80<br /> ? bind_evtchn_to_cpu+0xdf/0xf0<br /> ? exc_invalid_op+0x4e/0x70<br /> ? bind_evtchn_to_cpu+0xdf/0xf0<br /> ? asm_exc_invalid_op+0x12/0x20<br /> ? bind_evtchn_to_cpu+0xdf/0x<br /> ---truncated---