CVE-2025-40160

In the Linux kernel, the following vulnerability has been resolved:

xen/events: Return -EEXIST for bound VIRQs

Change find_virq() to return -EEXIST when a VIRQ is bound to a different CPU than the one passed in. With that, remove the BUG_ON() from bind_virq_to_irq() to propogate the error upwards.

Some VIRQs are per-cpu, but others are per-domain or global. Those must be bound to CPU0 and can then migrate elsewhere. The lookup for per-domain and global will probably fail when migrated off CPU 0, especially when the current CPU is tracked. This now returns -EEXIST instead of BUG_ON().

A second call to bind a per-domain or global VIRQ is not expected, but make it non-fatal to avoid trying to look up the irq, since we don't know which per_cpu(virq_to_irq) it will be in.

bind_virq_to_irq() used a BUG_ON(ret < 0) which could be triggered when a VIRQ was already bound to another CPU. The condition can legitimately happen for non-per-CPU VIRQs. This allowed a reachable kernel assertion and caused a fatal panic inside the Xen guest kernel. A local privileged kernel context (e.g., a driver or subsystem) calling bind_virq_to_irq() while a VIRQ is already assigned to a different CPU. A guest user can indirectly trigger this via timing and repeated binding operations. For the CVSS the PR:L, because only privileged kernel paths can directly trigger the VIRQ binding logic, but a local user can indirectly cause it by interacting with subsystems that manage event channels.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.