Bug 2222210 (CVE-2023-3750) - CVE-2023-3750 libvirt: improper locking in virStoragePoolObjListSearch may lead to denial of service
Summary: CVE-2023-3750 libvirt: improper locking in virStoragePoolObjListSearch may le...
Keywords:
Status: NEW
Alias: CVE-2023-3750
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody
QA Contact:
URL:
Whiteboard:
Depends On: 2223718 2221851 2222212 2222213
Blocks: 2222211
TreeView+ depends on / blocked
 
Reported: 2023-07-12 09:26 UTC by Mauro Matteo Cascella
Modified: 2023-11-07 08:16 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in libvirt. The virStoragePoolObjListSearch function does not return a locked pool as expected, resulting in a race condition and denial of service when attempting to lock the same object from another thread. This issue could allow clients connecting to the read-only socket to crash the libvirt daemon.
Clone Of:
Environment:
Last Closed:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2023:6409 0 None None None 2023-11-07 08:16:08 UTC

Description Mauro Matteo Cascella 2023-07-12 09:26:00 UTC 
virtqemud may get SIGABRT when run the pool-list & vol-info cmds for a rbd pool. An unprivileged user with RO connection can cause the daemon to crash.

Upstream patch:
https://listman.redhat.com/archives/libvir-list/2023-July/240776.html
Comment 2 Peter Krempa 2023-07-13 14:37:24 UTC 
In https://bugzilla.redhat.com/show_bug.cgi?id=2221851 especially https://bugzilla.redhat.com/show_bug.cgi?id=2221851#c7 I've analyzed the root cause to be a unlock of an unlocked mutex which another thread is currently atempting to lock and glibc abort()ing due to it.

The bug was caused by a refactor to automate unlocking which didn't see that we require the object locked when returning from a function. The bug is NOT specific to use of the RBD pool, but that seems to produce fauvorable timing to reproduce the issue.

I VERY strongly suggest that embargo is lifted to follow the usual upstream-first process.

RHEL-8 is not affected as it uses libvirt-8.0.0.
Comment 3 Mauro Matteo Cascella 2023-07-18 15:37:38 UTC 
Thanks Peter, I've updated the bug summary accordingly and assigned CVE-2023-3750. Since bug 2221851 is not publicly accessible, I'm posting here your comment:

---
The main problem is that we try to unlock a mutex which was not locked due to a bug in the aforementioned refactor.

Preferrably we upstream the commit first as doing a downstream fix first is too much of a hassle.

Broken versions are libvirt-8.3.0 and newer, when using APIs which lookup a storage pool by trying to refer to a volume:
virStorageVolLookupByName, virStorageVolLookupByPath, virStoragePoolLookupByTargetPath

Since it's a race condition it requires favourable timing which was achieved originally by using RBD, although a 'usleep()' as mentioned above is sufficient.
---

It would be great if you could send a patch v2 with 'Fixes: CVE-2023-3750' tag and 2222210 (this bug) in place of 2221851?
Comment 4 Mauro Matteo Cascella 2023-07-18 15:38:42 UTC 
Created libvirt tracking bugs for this issue:

Affects: fedora-all [bug 2223718]
Comment 5 Mauro Matteo Cascella 2023-07-25 10:10:19 UTC 
Upstream commit:
https://gitlab.com/libvirt/libvirt/-/commit/9a47442366fcf8a7b6d7422016d7bbb6764a1098
Comment 6 errata-xmlrpc 2023-11-07 08:16:05 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2023:6409 https://access.redhat.com/errata/RHSA-2023:6409
Note You need to log in before you can comment on or make changes to this bug.