Xenstored and guests communicate via a shared memory page using a
specific protocol. When a guest violates this protocol, xenstored will
drop the connection to that guest.

Unfortunately this is done by just removing the guest from xenstored's
internal management, resulting in the same actions as if the guest had
been destroyed, including sending an @releaseDomain event.

@releaseDomain events do not say guest has been removed.  All watchers
of this event must look at the states of all guests to find the guest
which has been removed.  When an @releaseDomain is generated due to
domain xenstored protocol violation, As the guest is still running, so
the watchers will not react.

Later, when the guest is actually destroyed, xenstored will no longer
have it stored in its internal data base, so no further @releaseDomain
event will be sent. This can lead to a zombie domain; memory mappings
of that guest's memory will not be removed, due to the missing
event. This zombie domain will be cleaned up only after another domain
is destroyed, as that will trigger another @releaseDomain event.

If the device model of the guest which violated the Xenstore protocol
is running in a stub-domain, a use-after-free case could happen in
xenstored, after having removed the guest from its internal data base,
possibly resulting in a crash of xenstored.