All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: qemu-devel@nongnu.org
Cc: kwolf@redhat.com, jasowang@redhat.com, fnu.vikram@xilinx.com,
	berrange@redhat.com, pisa@cmp.felk.cvut.cz
Subject: [PATCH 2/4] crypto: Forbid broken unloading of secrets
Date: Mon, 30 Nov 2020 11:56:13 +0100	[thread overview]
Message-ID: <20201130105615.21799-3-kwolf@redhat.com> (raw)
In-Reply-To: <20201130105615.21799-1-kwolf@redhat.com>

qcrypto_secret_prop_set_loaded() forgets to reset secret->rawdata after
unloading a secret, which will lead to a double free at some point.

Because there is no use case for unloading an already loaded secret
(apart from deleting the whole secret object) and we know that nobody
could use this because it would lead to crashes, let's just forbid the
operation instead of fixing the unloading.

Eventually, we'll want to get rid of 'loaded' in the external interface,
but for the meantime this is more consistent with rng, which has a
similar property 'opened' that also can't be reset to false after it
became true.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
 crypto/secret_common.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/crypto/secret_common.c b/crypto/secret_common.c
index 35b82cb531..714a15d5e5 100644
--- a/crypto/secret_common.c
+++ b/crypto/secret_common.c
@@ -191,9 +191,9 @@ qcrypto_secret_prop_set_loaded(Object *obj,
 
         secret->rawdata = input;
         secret->rawlen = inputlen;
-    } else {
-        g_free(secret->rawdata);
-        secret->rawlen = 0;
+    } else if (secret->rawdata) {
+        error_setg(errp, "Cannot unload secret");
+        return;
     }
 }
 
-- 
2.28.0



  parent reply	other threads:[~2020-11-30 11:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30 10:56 [PATCH 0/4] User creatable object property setting fixes Kevin Wolf
2020-11-30 10:56 ` [PATCH 1/4] crypto: Move USER_CREATABLE to secret_common base class Kevin Wolf
2020-11-30 10:56 ` Kevin Wolf [this message]
2020-11-30 10:56 ` [PATCH 3/4] crypto: Fix memory leaks in set_loaded for tls-* Kevin Wolf
2020-11-30 10:56 ` [PATCH 4/4] can-host: Fix crash when 'canbus' property is not set Kevin Wolf
2020-12-07 10:30 ` [PATCH 0/4] User creatable object property setting fixes Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201130105615.21799-3-kwolf@redhat.com \
    --to=kwolf@redhat.com \
    --cc=berrange@redhat.com \
    --cc=fnu.vikram@xilinx.com \
    --cc=jasowang@redhat.com \
    --cc=pisa@cmp.felk.cvut.cz \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.