CVE-2020-29483

Se detectó un problema en Xen versiones hasta 4.14.x. Xenstored y los invitados se comunican por medio de una página de memoria compartida usando un protocolo específico. Cuando un invitado viola este protocolo, xenstored interrumpirá la conexión con ese invitado. Desafortunadamente, esto se hace simplemente eliminando al invitado de la administración interna de xenstored, resultando en las mismas acciones como si el invitado hubiera sido destruido, incluyendo el envío de un evento @releaseDomain. Los eventos de @releaseDomain no dicen que el invitado ha sido eliminado. Todos los observadores de este evento deben mirar los estados de todos los invitados para encontrar al invitado que ha sido eliminado. Cuando @releaseDomain es generada debido a una violación del protocolo xenstored del dominio, porque el invitado aún se está ejecutando, los observadores no reaccionarán. Más tarde, cuando el invitado sea realmente destruido, xenstored ya no lo tendrá almacenado en su base de datos interna, por lo que no más eventos @releaseDomain serán enviados. Esto puede conllevar a un dominio zombi; Las asignaciones de la memoria de ese invitado no serán eliminadas debido a una falta de evento. Este dominio zombie será limpiado solo después de que otro dominio sea destruido, ya que eso activará otro evento @releaseDomain. Si el modelo de dispositivo del invitado que violó el protocolo de Xenstore se está ejecutando en un dominio stub, un caso de uso de la memoria previamente liberada podría ocurrir en xenstored, después de haber eliminado al invitado de su base de datos interna, resultando posiblemente en un bloqueo de xenstored. Un invitado malicioso puede bloquear los recursos del host durante un período después de su propia muerte. Los invitados con un modelo de dispositivo de dominio stub pueden eventualmente bloquearse en xenstored, resultando en una denegación de servicio más grave (la prevención de cualquier otra operación de administración de dominio). Solo la variante C de Xenstore está afectada; la variante Ocaml no está afectada. Solo los invitados de HVM con un modelo de dispositivo falso pueden causar una DoS grave