CVE-2026-90310: xen/xenbus: check otherend_id only after it has been initialized
In the Linux kernel, the following vulnerability has been resolved:
xen/xenbus: check otherendid only after it has been initialized
When device just got initialized (for example on module load), the otherendid field is initialized only after xenbusreadotherenddetails() gets called. If xenstore watch triggers xenbusdevchanged() before that, it might consider still zeroed otherendid field (not matching actual xenstore content) as a sign of device state reset. It can happen because xenstore watch are handled in another thread (xenwatch), which can run in parallel to the initial device probe running at module load. In that case, it would call deviceunregister(), which would deadlock against device probe from module init.
Fix this by considering dev->otherendid change only after dev->otherend is set (which happen after otherendid is initialized).
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.