A flaw was found in the libvirt virStoragePoolLookupByTargetPath API. The storagePoolLookupByTargetPath() function does not properly release a locked object (virStoragePoolObj) on ACL permission failure. Clients connecting to the read-write socket with limited ACL permissions could use this flaw to acquire the lock and prevent other users from accessing storage pool/volume APIs, resulting in a denial of service condition. Upstream fix: https://libvirt.org/git/?p=libvirt.git;a=commit;h=447f69dec47e1b0bd15ecd7cd49a9fd3b050fb87
Created libvirt tracking bugs for this issue: Affects: fedora-all [bug 1986113]
This bug was introduced in libvirt-4.1.0 when virStoragePoolLookupByTargetPath was exported as a public API with commit: https://libvirt.org/git/?p=libvirt.git;a=commit;h=7aa0e8c0cb8a6293d0c6f7e3d29c13b96dec2129
By default no access control checks are done once a client has authenticated with libvirtd. An authenticated user is allowed access to all libvirt API calls. Libvirt provides support for fine grained per-API access control via polkit, by enabling the 'polkit' access control driver. This issue allows a denial of service on a libvirt socket that has been configured with polkit fine grained access controls. The attack vector is "Network" since libvirt can be optionally enabled for remote access over TCP (together with polkit access control).
This issue has been addressed in the following products: Advanced Virtualization for RHEL 8.4.0.Z Via RHSA-2021:3703 https://access.redhat.com/errata/RHSA-2021:3703
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-3667
This issue has been addressed in the following products: Advanced Virtualization for RHEL 8.2.1 Via RHSA-2021:3704 https://access.redhat.com/errata/RHSA-2021:3704
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:4191 https://access.redhat.com/errata/RHSA-2021:4191