https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 08 Oct 2026 06:52:20 +0000 https://cve.radiocsirt.org/vuln/cve-2024-26687 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>xen/events: close evtchn after mapping cleanup</p> <p>shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can&#39;t due to lock inversion. Both are called with the irq_desc-&gt;lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc-&gt;lock.</p> <p>This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel:</p> <p>CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -&gt; returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } }</p> <p>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).</p> <p>- __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn&#39;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.</p> <p>The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it&#39;s potential previous evt…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>xen/events: close evtchn after mapping cleanup</p> <p>shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can&#39;t due to lock inversion. Both are called with the irq_desc-&gt;lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc-&gt;lock.</p> <p>This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel:</p> <p>CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -&gt; returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } }</p> <p>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).</p> <p>- __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn&#39;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.</p> <p>The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it&#39;s potential previous evt…</p> https://cve.radiocsirt.org/vuln/cve-2024-26687