On 09/02/2015 06:57 AM, John Ferlan wrote:
On 09/02/2015 08:25 AM, Ján Tomko wrote:
On Tue, Sep 01, 2015 at 08:55:58PM -0400, John Ferlan wrote:
In an NFS root-squash environment it was possible that if the just created volume from XML wasn't properly created with the right uid/gid and/or mode, then the followup refreshVol will fail to open the volume in order to get the allocation/capacity values. This would leave the volume still on the server and cause a libvirtd crash because 'voldef' would be in the pool list, but the cleanup code would free it.
It would be nice to blame the commit that broke this, released in 1.2.14: commit 155ca616eb231181f6978efc9e3a1eb0eb60af8a Allow creating volumes with a backing store but no capacity (preferably without mentioning the author's name ;)
Oh right - I did it in my writeup but not the commit message... I'll add before pushing. Although without patch 3, getting a failure from refreshVol was perhaps less likely, but not impossible.
Also, is there a bug that can be made public and linked here?
There is a bz, but it's not public (yet) - the process is ongoing.
The issue has been assigned CVE-2015-5247. John took correct steps of first informing the libvirt-security list where we discussed the effect of the bug (the CVE is there mainly if you use fine-grained ACLs); and I am now in the process of writing up a proper Libvirt Security Notice as well as helping backport these patches to affected branches. We'll add signed CVE- tags to libvirt.git before all is said and done. It missed the 1.2.19 release, so these will be the first patches on the new v1.2.19-maint branch. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org