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@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