|Description||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.|
|Source||CVE (at NVD; CERT, LWN, oss-sec, fulldisc, bugtraq, EDB, Metasploit, Red Hat, Ubuntu, Gentoo, SUSE bugzilla/CVE, Mageia, GitHub advisories/code/issues, web search, more)|
Vulnerable and fixed packages
The table below lists information on source packages.
|xen (PTS)||buster, buster (security)||4.11.4+107-gef32c7afa2-1||vulnerable|
|bullseye (security), bullseye||4.14.5+94-ge49571868d-1||fixed|
The information below is based on the following data on fixed versions.
|Package||Type||Release||Fixed Version||Urgency||Origin||Debian Bugs|
[buster] - xen <end-of-life> (DSA 4677-1)
[stretch] - xen <end-of-life> (DSA 4602-1)