Mishandling of uninitialised FIFO-based event channel control blocks:
When using the FIFO-based event channels, there are no checks for the existence of a control block when binding an event or moving it to a different VCPU. This is because events may be bound when the ABI is in 2-level mode (e.g., by the toolstack before the domain is started). The guest may trigger a Xen crash in evtchn_fifo_set_pending() if:
- the event is bound to a VCPU without a control block; or
- VCPU 0 does not have a control block.
In case (a), Xen will crash when looking up the current queue. In (b), Xen will crash when looking up the old queue (which defaults to a queue on VCPU 0).
lack of check (missing control block for event)
By allocating all the per-VCPU structures when enabling the FIFO ABI, we can be sure that v->evtchn_fifo is always valid.
EVTCHNOP_init_control_block for all the other CPUs need only map the shared control block.
A single check in evtchnfifoset_pending() before accessing the control block fixes all cases where the guest has not initialized some control blocks.
add some checks and initialization.
A buggy or malicious guest can crash the host.