CVE-2024-26687 in Linux
Summary
by MITRE • 04/03/2024
In the Linux kernel, the following vulnerability has been resolved:
xen/events: close evtchn after mapping cleanup
shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock.
This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel:
CPU0 CPU1 shutdown_pirq {
xen_evtchn_close(e) __startup_pirq {
EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() {
set_evtchn_to_irq(e, -1) } }
Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1).
- __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq.
The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup.
On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe
devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel.
------------[ cut here ]------------
blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI
CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 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 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 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---
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/03/2025
The vulnerability described in CVE-2024-26687 resides within the Linux kernel's Xen hypervisor event handling subsystem, specifically affecting the interaction between event channel management and interrupt mapping operations. This flaw manifests as a race condition during the shutdown and startup of physical interrupt requests, leading to potential kernel panics and system instability. The core issue stems from improper lock ordering and sequence of operations when managing event channels in Xen virtualized environments, where the kernel attempts to close event channels before properly cleaning up their associated mappings. This vulnerability directly impacts the xen/events subsystem and is categorized under CWE-362, which denotes a race condition in kernel-level code.
The technical flaw occurs due to a lock inversion scenario where shutdown_pirq and startup_pirq functions attempt to operate without acquiring the irq_mapping_update_lock, which is required to maintain consistency but cannot be acquired due to existing lock dependencies. The lock ordering constraint requires that irq_mapping_update_lock be acquired before irq_desc->lock, yet during interrupt shutdown and startup operations, the reverse order is enforced, creating a window for concurrent access. When a shutdown_pirq operation is interrupted by a startup_pirq call, it can result in an event channel being freed while another thread attempts to bind a new interrupt to that same channel number, causing the evtchn_to_irq mapping to become invalid. This race condition is particularly dangerous because it can lead to kernel BUGs and system crashes, as evidenced by the reported panic during NVMe device probing.
The operational impact of this vulnerability is severe, especially in systems with multiple virtualized devices such as NVMe storage controllers where numerous interrupt mappings are established and torn down during system boot. During NVMe device initialization, the pci_free_irq function calls shutdown_pirq multiple times, while startup_pirq operations may occur concurrently, significantly increasing the probability of hitting the race condition. The vulnerability affects kernel versions prior to commit 3fcdaf3d7634 and can result in kernel panics with invalid opcode errors, specifically during the bind_evtchn_to_cpu function execution. The system becomes unstable as interrupt mappings become corrupted, potentially leading to data loss, system hangs, or complete system crashes during critical boot phases or device management operations.
The fix implemented addresses the root cause by reordering the cleanup sequence to first remove the event channel mappings before closing the event channel itself. This ensures that when a new event channel is allocated, any previous mappings are already cleared, maintaining consistency with the allocation order where event channels are first allocated and then mappings are established. This approach follows the principle of reverse order cleanup, which prevents the race condition where a newly allocated event channel could be assigned to a mapping that is still in the process of being freed. The mitigation aligns with ATT&CK technique T1059.001, which involves kernel-level code execution, and specifically addresses the privilege escalation and system stability threats that could arise from improper resource management in virtualized environments. This fix ensures that interrupt handling remains consistent and predictable, particularly in high-concurrency scenarios involving multiple device drivers and virtualized interrupt management.