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.
Weakness
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
Affected Software
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Xen | Xen | 4.0.0 (including) | 4.12.0 (excluding) |
| Xen | Xen | 4.13.0 (including) | 4.14.0 (excluding) |
| Xen | Xen | 4.15.0 (including) | 4.16.0 (excluding) |
| Xen | Ubuntu | bionic | * |
| Xen | Ubuntu | focal | * |
| Xen | Ubuntu | impish | * |
| Xen | Ubuntu | kinetic | * |
| Xen | Ubuntu | lunar | * |
| Xen | Ubuntu | mantic | * |
| Xen | Ubuntu | oracular | * |
| Xen | Ubuntu | plucky | * |
| Xen | Ubuntu | trusty | * |
| Xen | Ubuntu | xenial | * |
Extended Description
Locking is a type of synchronization behavior that ensures that multiple independently-operating processes or threads do not interfere with each other when accessing the same resource. All processes/threads are expected to follow the same steps for locking. If these steps are not followed precisely - or if no locking is done at all - then another process/thread could modify the shared resource in a way that is not visible or predictable to the original process. This can lead to data or memory corruption, denial of service, etc.
Potential Mitigations
Related Attack Patterns
- https://cwe.mitre.org/data/definitions/25.html
- https://cwe.mitre.org/data/definitions/26.html
- https://cwe.mitre.org/data/definitions/27.html
References
- http://www.openwall.com/lists/oss-security/2022/04/05/1
- http://xenbits.xen.org/xsa/advisory-397.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6ETPM2OVZZ6KOS2L7QO7SIW6XWT5OW3F/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UHFSRVLM2JUCPDC2KGB7ETPQYJLCGBLD/
- https://security.gentoo.org/glsa/202402-07
- https://www.debian.org/security/2022/dsa-5117
- https://xenbits.xenproject.org/xsa/advisory-397.txt
- http://www.openwall.com/lists/oss-security/2022/04/05/1
- http://xenbits.xen.org/xsa/advisory-397.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6ETPM2OVZZ6KOS2L7QO7SIW6XWT5OW3F/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UHFSRVLM2JUCPDC2KGB7ETPQYJLCGBLD/
- https://security.gentoo.org/glsa/202402-07
- https://www.debian.org/security/2022/dsa-5117
- https://xenbits.xenproject.org/xsa/advisory-397.txt