CVE-2024-26687
Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
03/04/2024
Last modified:
17/03/2025
Description
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&#39;t due to lock inversion. Both<br />
are called with the irq_desc->lock being taking. The lock order,<br />
however, is first irq_mapping_update_lock and then irq_desc->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 />
-> 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&#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&#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&#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---
Impact
Base Score 3.x
5.50
Severity 3.x
MEDIUM
Vulnerable products and versions
CPE | From | Up to |
---|---|---|
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 2.6.37 (including) | 6.1.81 (excluding) |
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 6.2 (including) | 6.6.19 (excluding) |
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 6.7 (including) | 6.7.6 (excluding) |
cpe:2.3:o:linux:linux_kernel:6.8:rc1:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.8:rc2:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.8:rc3:*:*:*:*:*:* | ||
cpe:2.3:o:linux:linux_kernel:6.8:rc4:*:*:*:*:*:* | ||
cpe:2.3:o:debian:debian_linux:10.0:*:*:*:*:*:*:* |
To consult the complete list of CPE names with products and versions, see this page
References to Advisories, Solutions, and Tools
- https://git.kernel.org/stable/c/0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd
- https://git.kernel.org/stable/c/20980195ec8d2e41653800c45c8c367fa1b1f2b4
- https://git.kernel.org/stable/c/585a344af6bcac222608a158fc2830ff02712af5
- https://git.kernel.org/stable/c/9470f5b2503cae994098dea9682aee15b313fa44
- https://git.kernel.org/stable/c/9be71aa12afa91dfe457b3fb4a444c42b1ee036b
- https://git.kernel.org/stable/c/ea592baf9e41779fe9a0424c03dd2f324feca3b3
- https://git.kernel.org/stable/c/fa765c4b4aed2d64266b694520ecb025c862c5a9
- https://git.kernel.org/stable/c/0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd
- https://git.kernel.org/stable/c/20980195ec8d2e41653800c45c8c367fa1b1f2b4
- https://git.kernel.org/stable/c/585a344af6bcac222608a158fc2830ff02712af5
- https://git.kernel.org/stable/c/9470f5b2503cae994098dea9682aee15b313fa44
- https://git.kernel.org/stable/c/9be71aa12afa91dfe457b3fb4a444c42b1ee036b
- https://git.kernel.org/stable/c/ea592baf9e41779fe9a0424c03dd2f324feca3b3
- https://git.kernel.org/stable/c/fa765c4b4aed2d64266b694520ecb025c862c5a9
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html