CVE-2026-90310: xen/xenbus: check otherend_id only after it has been initialized
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In xen/xenbus, modify the logic so otherend_id is checked only after it has been initialized (i.e., ensure xenbus_dev_changed() does not evaluate otherend_id before xenbus_read_otherend_details() initializes it).
xen/xenbus check otherend_id only after it has been initialized = defer otherend_id checks until after xenbus_read_otherend_details() has been called and otherend_id is initialized
Event History
Frequently Asked Questions
What condition triggers the deadlock?
A Xenstore watch must invoke xenbus_dev_changed() while a device is still being initially probed, before xenbus_read_otherend_details() has initialized otherend_id. This race can occur because the xenwatch thread runs in parallel with the device probe, including during module load.
What is the practical impact of the race?
The uninitialized, zeroed otherend_id can be treated as a device-state reset when it does not match Xenstore content. xenbus_dev_changed() can then call device_unregister(), which deadlocks against the ongoing device probe from module initialization.
How does the resolved change prevent the issue?
The change considers otherend_id changes only after dev->otherend has been set. dev->otherend is set after otherend_id has been initialized, preventing the early Xenstore watch from acting on the zeroed field.