Bug 2222210 (CVE-2023-3750)
| Summary: | CVE-2023-3750 libvirt: improper locking in virStoragePoolObjListSearch may lead to denial of service | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Mauro Matteo Cascella <mcascell> |
| Component: | vulnerability | Assignee: | Nobody <nobody> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | berrange, ddepaula, eblake, jdenemar, jferlan, jsuchane, knoel, libvirt-maint, pkrempa, security-response-team, virt-maint, ymankad |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2221851, 2222212, 2222213, 2223718 | ||
| Bug Blocks: | 2222211 | ||
|
Description
Mauro Matteo Cascella
2023-07-12 09:26:00 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. 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? Created libvirt tracking bugs for this issue: Affects: fedora-all [bug 2223718] Upstream commit: https://gitlab.com/libvirt/libvirt/-/commit/9a47442366fcf8a7b6d7422016d7bbb6764a1098 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 |