Racy interactions between dirty vram tracking and paging log dirty hypercalls Activation of log dirty mode done by XEN_DMOP_track_dirty_vram (was named HVMOP_track_dirty_vram before Xen 4.9) is racy with ongoing log dirty hypercalls. A suitably timed call to XEN_DMOP_track_dirty_vram can enable log dirty while another CPU is still in the process of tearing down the structures related to a previously enabled log dirty mode (XEN_DOMCTL_SHADOW_OP_OFF). This is due to lack of mutually exclusive locking between both operations and can lead to entries being added in already freed slots, resulting in a memory leak.
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
| Link | Tags |
|---|---|
| https://xenbits.xenproject.org/xsa/advisory-397.txt | third party advisory |
| http://xenbits.xen.org/xsa/advisory-397.html | third party advisory patch |
| http://www.openwall.com/lists/oss-security/2022/04/05/1 | mailing list third party advisory patch |
| https://www.debian.org/security/2022/dsa-5117 | third party advisory vendor advisory |
| https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UHFSRVLM2JUCPDC2KGB7ETPQYJLCGBLD/ | vendor advisory |
| https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6ETPM2OVZZ6KOS2L7QO7SIW6XWT5OW3F/ | vendor advisory |
| https://security.gentoo.org/glsa/202402-07 | vendor advisory |