A flaw was found in libvirt. A pool created without a target path may lead to segmentation fault and denial of service. This issue may be triggered by a read only user. References: https://bugzilla.redhat.com/show_bug.cgi?id=1790725
Upstream fix: https://libvirt.org/git/?p=libvirt.git;a=commit;h=dfff16a7c261f8d28e3abe60a47165f845fa952f
Created libvirt tracking bugs for this issue: Affects: fedora-all [bug 1820690]
Statement: Versions of `libvirt` as shipped with Red Hat Enterprise Linux 5 and 6 are marked as "notaffected" as they do not include the vulnerable code, which was introduced in a later version of the package. Specifically, the affected internal function `storagePoolLookupByTargetPathCallback` was introduced in `libvirt` upstream version v3.10.0, whereas the `virStoragePoolLookupByTargetPath` method was exported as a public API in version 4.1.0.
In reply to comment #7: > Specifically, the affected internal function `storagePoolLookupByTargetPathCallback` was introduced in `libvirt` upstream version v3.10.0 Upstream commit: https://libvirt.org/git/?p=libvirt.git;a=commit;h=5d5c732d748d644ec14626bce448e84bdc4bd93e > whereas the `virStoragePoolLookupByTargetPath` method was exported as a public API in version 4.1.0 Upstream commit: https://libvirt.org/git/?p=libvirt.git;a=commit;h=7aa0e8c0cb8a6293d0c6f7e3d29c13b96dec2129
In order to exploit this flaw, a storage pool with no target path must already exist. Given this precondition, an unprivileged user with a read-only connection may trigger the flaw by calling the public API virStoragePoolLookupByTargetPath with an empty path (''). This API eventually calls the vulnerable callback function through virStoragePoolObjListSearch(), leading to a segmentation fault due to a NULL pointer dereference: ``` Backtrace: #0 0x00007ff55604ebbe in __strcmp_sse2 () #1 0x00007ff538c9f990 in storagePoolLookupByTargetPathCallback (opaque=0x7ff53003c400, obj=0x7ff53c0039a0) #2 0x00007ff538c9f990 in storagePoolLookupByTargetPathCallback (obj=0x7ff53c0039a0, opaque=0x7ff53003c400) #3 0x00007ff559cc548f in virStoragePoolObjListSearchCb (payload=0x7ff53c0039a0, name=<optimized out>, opaque=0x7ff542050780) #4 0x00007ff559be41c5 in virHashSearch (name=<optimized out>, data=<optimized out>, iter=<optimized out>, ctable=<optimized out>) #5 0x00007ff559be41c5 in virHashSearch (ctable=0x7ff4e40f6450, iter=iter@entry=0x7ff559cc5470 <virStoragePoolObjListSearchCb>, data=data@entry=0x7ff542050780, name=name@entry=0x0) #6 0x00007ff559cc66f0 in virStoragePoolObjListSearch (pools=0x7ff4e40f9a50, searcher=searcher@entry=0x7ff538c9f960 <storagePoolLookupByTargetPathCallback>, opaque=opaque@entry=0x7ff53003c400) #7 0x00007ff538c9e676 in storagePoolLookupByTargetPath (conn=0x7ff53c002530, path=0x7ff53003c2d0 "") #8 0x00007ff559df9595 in virStoragePoolLookupByTargetPath (conn=0x7ff53c002530, path=0x7ff53003c2d0 "") ```
Acknowledgments: Name: Han Han (Red Hat)
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:4000 https://access.redhat.com/errata/RHSA-2020:4000
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-2020-10703
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:4676 https://access.redhat.com/errata/RHSA-2020:4676