On Tue, Jun 05, 2018 at 16:34:47 -0400, John Ferlan wrote:
Commit id 02b031a4 added a secondary path from which the
incoming @secinfo would not be free'd until the private
data was freed in qemuDomainStorageSourcePrivateDispose.
However, by doing this the original intention to free
@*secinfo afterwards is lost and thus the pass by value
of the secinfo->s.aes (or secinfo->s.plain for its method)
results in not keeping the NULL setting in the various
secret.{username|iv|ciphertext} fields upon return to
qemuDomainSecretInfoClear and eventually will result in
a double free at domain destroy:
raise ()
abort ()
__libc_message ()
malloc_printerr ()
_int_free ()
virFree
qemuDomainSecretAESClear
qemuDomainSecretInfoClear
qemuDomainSecretInfoFree
qemuDomainStorageSourcePrivateDispose
virObjectUnref
virStorageSourceClear
virStorageSourceFree
virDomainDiskDefFree
virDomainDefFree
virDomainObjRemoveTransientDef
qemuProcessStop
qemuDomainDestroyFlags
virDomainDestroy
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
src/qemu/qemu_domain.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
Domains w/ secrets weren't very happy when I went to destroy them
today during testing...
Fortunately issue is not in 4.4.0...
I modified both Plain and AES just because it's probably best to
avoid something like this in the future.
Yep, I did not notice that in the first place.
ACK