cbcvebase.
CVE-2024-26687
published 2024-04-03

CVE-2024-26687: In the Linux kernel, the following vulnerability has been resolved: xen/events: close evtchn after mapping cleanup shutdown_pirq and startup_pirq are not…

PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.23%
13.7th percentile
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 f

Affected

24 ranges
VendorProductVersion rangeFixed in
debiandebian_linux
debianlinux< linux 6.1.82-1 (bookworm)linux 6.1.82-1 (bookworm)
linuxlinux
linuxlinux>= d46a78b05c0e37f76ddf4a7a67bf0b6c68bada55 < 9470f5b2503cae994098dea9682aee15b313fa449470f5b2503cae994098dea9682aee15b313fa44
linuxlinux>= d46a78b05c0e37f76ddf4a7a67bf0b6c68bada55 < 0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd
linuxlinux>= d46a78b05c0e37f76ddf4a7a67bf0b6c68bada55 < ea592baf9e41779fe9a0424c03dd2f324feca3b3ea592baf9e41779fe9a0424c03dd2f324feca3b3
linuxlinux>= d46a78b05c0e37f76ddf4a7a67bf0b6c68bada55 < 585a344af6bcac222608a158fc2830ff02712af5585a344af6bcac222608a158fc2830ff02712af5
linuxlinux>= d46a78b05c0e37f76ddf4a7a67bf0b6c68bada55 < 20980195ec8d2e41653800c45c8c367fa1b1f2b420980195ec8d2e41653800c45c8c367fa1b1f2b4
linuxlinux>= d46a78b05c0e37f76ddf4a7a67bf0b6c68bada55 < 9be71aa12afa91dfe457b3fb4a444c42b1ee036b9be71aa12afa91dfe457b3fb4a444c42b1ee036b
linuxlinux>= d46a78b05c0e37f76ddf4a7a67bf0b6c68bada55 < fa765c4b4aed2d64266b694520ecb025c862c5a9fa765c4b4aed2d64266b694520ecb025c862c5a9
linuxlinux_kernel
linuxlinux_kernel>= 0 < 5.10.216-15.10.216-1
linuxlinux_kernel>= 0 < 6.1.82-16.1.82-1
linuxlinux_kernel>= 0 < 6.7.7-16.7.7-1
linuxlinux_kernel>= 0 < 6.7.7-16.7.7-1
linuxlinux_kernel>= 0 < 5.4.0-189.2095.4.0-189.209
linuxlinux_kernel>= 0 < 5.15.0-116.1265.15.0-116.126
linuxlinux_kernel>= 0 < 4.4.0-258.2924.4.0-258.292
linuxlinux_kernel>= 0 < 4.15.0-228.2404.15.0-228.240
linuxlinux_kernel>= 2.6.37 < 6.1.816.1.81
linuxlinux_kernel>= 6.2 < 6.6.196.6.19
linuxlinux_kernel>= 6.7 < 6.7.66.7.6
msrccbl2_kernel_5.15.176.3-3_on_cbl_mariner_2.0
msrccbl2_kernel_5.15.182.1-1_on_cbl_mariner_2.0

CVSS provenance

nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv7.0HIGH
vendor_ubuntu7.0HIGH
vendor_debian5.5MEDIUM
vendor_msrc5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.