Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#67807 - [libvirt] [security] CVE-2020-14339

Attached to Project: Community Packages
Opened by loqs (loqs) - Wednesday, 02 September 2020, 14:43 GMT
Last edited by Robin Broda (coderobe) - Tuesday, 15 September 2020, 00:45 GMT
Task Type Bug Report
Category Security
Status Closed
Assigned To Levente Polyak (anthraxx)
Robin Broda (coderobe)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


A flaw was found in libvirt, where it leaked a file descriptor for `/dev/mapper/control` into the QEMU process. This file descriptor allows for privileged operations to happen against the device-mapper on the host. This flaw allows a malicious guest user or process to perform operations outside of their standard permissions, potentially causing serious damage to the host operating system.
Fixed in libvirt 6.6.0.

Additional info:
* libvirt 6.5.0-1
This task depends upon

Closed by  Robin Broda (coderobe)
Tuesday, 15 September 2020, 00:45 GMT
Reason for closing:  Fixed
Additional comments about closing:  patched in libvirt 6.5.0-2
Comment by Robin Broda (coderobe) - Thursday, 03 September 2020, 13:40 GMT
Similar to libvirt 6.6.0, 6.7.0 is now signed by 453B65310595562855471199CA68BE8010084C9C instead of C74415BA7C9C7F78F02E1DC34606B8A5DE95BC1F. No web of trust can be established from me to 453B65310595562855471199CA68BE8010084C9C and there are no sigs from the previous maintainer on the key either.

Deferred until redhat fixes their releng
Comment by Robin Broda (coderobe) - Thursday, 03 September 2020, 14:01 GMT
Tried backporting the patch but it does not apply cleanly on top of 6.5.0, one hunk fails to apply.
Comment by loqs (loqs) - Thursday, 03 September 2020, 17:14 GMT
I was able to cherry pick 22494556542c676d1b9e7f1c1f2ea13ac17e1e3e and the three other commits from the same patch request [1] after c6a0d3ff8b4ead3b1f38a40668df65f152cc2f32.
Commits cherry-picked in the following order:
Attached test.patch of diff against v6.5.0 after cherry-picking the above.
Dropping the unrelated PO file change c6a0d3ff8b4ead3b1f38a40668df65f152cc2f32 and manually merging 22494556542c676d1b9e7f1c1f2ea13ac17e1e3e produced test2.patch.

I agree it is not worth applying and can wait for 6.6 / 6.7.

Comment by Robin Broda (coderobe) - Tuesday, 15 September 2020, 00:41 GMT
It's now ~two more weeks after this without any noise from redhat regarding their signing, so i'll be applying your patch2 for the time being.
Thanks a lot for actually bothering to pick through the changes, solid contributions as usual from you :)