Bug 1816650 (CVE-2020-10703) - CVE-2020-10703 libvirt: Potential denial of service via active pool without target path
Summary: CVE-2020-10703 libvirt: Potential denial of service via active pool without t...
Keywords:
Status: NEW
Alias: CVE-2020-10703
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1820692 1820694 1790725 1820690 1820691 1826869
Blocks: 1816652
TreeView+ depends on / blocked
 
Reported: 2020-03-24 13:20 UTC by Pedro Sampaio
Modified: 2020-05-04 15:56 UTC (History)
15 users (show)

Fixed In Version: libvirt 6.0.0
Doc Type: If docs needed, set a value
Doc Text:
A NULL pointer dereference was found in the libvirt API responsible for fetching a storage pool based on its target path. In more detail, this flaw affects storage pools created without a target path such as network-based pools like gluster and RBD. Unprivileged users with a read-only connection could abuse this flaw to crash the libvirt daemon, resulting in a potential denial of service.
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Pedro Sampaio 2020-03-24 13:20:53 UTC
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

Comment 3 Mauro Matteo Cascella 2020-04-03 15:39:47 UTC
Created libvirt tracking bugs for this issue:

Affects: fedora-all [bug 1820690]

Comment 7 Mauro Matteo Cascella 2020-05-04 14:46:07 UTC
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.

Comment 8 Mauro Matteo Cascella 2020-05-04 14:50:55 UTC
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

Comment 9 Mauro Matteo Cascella 2020-05-04 15:39:34 UTC
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 "")
```

Comment 11 Mauro Matteo Cascella 2020-05-04 15:56:47 UTC
Acknowledgments:

Name: Han Han (Red Hat)


Note You need to log in before you can comment on or make changes to this bug.