qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: zhenwei pi <pizhenwei@bytedance.com>
Cc: qemu-devel@nongnu.org,  arei.gonglei@huawei.com
Subject: Re: [PATCH] cryptodev: Fix error handling in cryptodev_lkcf_execute_task()
Date: Wed, 12 Mar 2025 13:02:09 +0100	[thread overview]
Message-ID: <87r032ihj2.fsf@pond.sub.org> (raw)
In-Reply-To: <df42e188-00b7-46cc-8853-163798c62ac2@bytedance.com> (zhenwei pi's message of "Wed, 12 Mar 2025 18:28:51 +0800")

zhenwei pi <pizhenwei@bytedance.com> writes:

> On 3/12/25 18:11, Markus Armbruster wrote:
>> When cryptodev_lkcf_set_op_desc() fails, we report an error, but
>> continue anyway.  This is wrong.  We then pass a non-null @local_error
>> to various functions, which could easily fail error_setv()'s assertion
>> on failure.
>> 
>> Fail the function instead.
>> 
>> When qcrypto_akcipher_new() fails, we fail the function without
>> reporting the error.  This leaks the Error object.
>> 
>> Add the missing error reporting.  This also frees the Error object.
>> 
>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>> ---
>>   backends/cryptodev-lkcf.c | 3 +++
>>   1 file changed, 3 insertions(+)
>> 
>> diff --git a/backends/cryptodev-lkcf.c b/backends/cryptodev-lkcf.c
>> index 41cf24b737..352c3e8958 100644
>> --- a/backends/cryptodev-lkcf.c
>> +++ b/backends/cryptodev-lkcf.c
>> @@ -330,6 +330,8 @@ static void cryptodev_lkcf_execute_task(CryptoDevLKCFTask *task)
>>               cryptodev_lkcf_set_op_desc(&session->akcipher_opts, op_desc,
>>                                          sizeof(op_desc), &local_error) != 0) {
>>               error_report_err(local_error);
>> +            status = -VIRTIO_CRYPTO_ERR;
>> +            goto out;
>>           } else {
>>               key_id = add_key(KCTL_KEY_TYPE_PKEY, "lkcf-backend-priv-key",
>>                                p8info, p8info_len, KCTL_KEY_RING);
>> @@ -346,6 +348,7 @@ static void cryptodev_lkcf_execute_task(CryptoDevLKCFTask *task)
>>                                           session->key, session->keylen,
>>                                           &local_error);
>>           if (!akcipher) {
>> +            error_report_err(local_error);
>>               status = -VIRTIO_CRYPTO_ERR;
>>               goto out;
>>           }
>
> What about moving several 'error_report_err(local_error);' to:
>
> out:
> if (local_error) {
>      error_report_err(local_error);
> }

I figure you suggest something like the appended patch.  But this led me
to another question.  Consider:

        asym_op_info = task->op_info->u.asym_op_info;
        switch (op_code) {
        case VIRTIO_CRYPTO_AKCIPHER_ENCRYPT:
            if (key_id >= 0) {
                ret = keyctl_pkey_encrypt(key_id, op_desc,
                    asym_op_info->src, asym_op_info->src_len,
                    asym_op_info->dst, asym_op_info->dst_len);

When keyctl_pkey_encrypt() fails, @local_error remains unset.

            } else {
                ret = qcrypto_akcipher_encrypt(akcipher,
                    asym_op_info->src, asym_op_info->src_len,
                    asym_op_info->dst, asym_op_info->dst_len, &local_error);
            }
            break;

        [More cases that can also fail without setting @local_error]

        default:
            error_setg(&local_error, "Unknown opcode: %u", op_code);
            status = -VIRTIO_CRYPTO_ERR;
            goto out;
        }

        if (ret < 0) {

The switch failed.

            if (!local_error) {

If it failed without setting @local_error, we report a generic error
*unless* errno is EKEYREJECTED.

Aside: checking errno this far from whatever set it is asking for
trouble.  It gets overwritten easily.

                if (errno != EKEYREJECTED) {
                    error_report("Failed do operation with keyctl: %d", errno);
                }

If it failed with setting @local_error, we report that error.

            } else {
                error_report_err(local_error);
            }
            status = op_code == VIRTIO_CRYPTO_AKCIPHER_VERIFY ?
                -VIRTIO_CRYPTO_KEY_REJECTED : -VIRTIO_CRYPTO_ERR;

Status set to negative value.  This will be assigned to task->status
below.

It can therefore become negative *silently* (i.e. without an error
report).  Why is this okay?

        } else {
            status = VIRTIO_CRYPTO_OK;
            asym_op_info->dst_len = ret;
        }

    out:
        if (key_id >= 0) {
            keyctl_unlink(key_id, KCTL_KEY_RING);
        }
        task->status = status;



diff --git a/backends/cryptodev-lkcf.c b/backends/cryptodev-lkcf.c
index 41cf24b737..0e20797cb3 100644
--- a/backends/cryptodev-lkcf.c
+++ b/backends/cryptodev-lkcf.c
@@ -329,7 +329,8 @@ static void cryptodev_lkcf_execute_task(CryptoDevLKCFTask *task)
                                            &local_error) != 0 ||
             cryptodev_lkcf_set_op_desc(&session->akcipher_opts, op_desc,
                                        sizeof(op_desc), &local_error) != 0) {
-            error_report_err(local_error);
+            status = -VIRTIO_CRYPTO_ERR;
+            goto out;
         } else {
             key_id = add_key(KCTL_KEY_TYPE_PKEY, "lkcf-backend-priv-key",
                              p8info, p8info_len, KCTL_KEY_RING);
@@ -410,10 +411,9 @@ static void cryptodev_lkcf_execute_task(CryptoDevLKCFTask *task)
     if (ret < 0) {
         if (!local_error) {
             if (errno != EKEYREJECTED) {
-                error_report("Failed do operation with keyctl: %d", errno);
+                error_setg_errno(&local_error,
+                                 "Failed do operation with keyctl: %d");
             }
-        } else {
-            error_report_err(local_error);
         }
         status = op_code == VIRTIO_CRYPTO_AKCIPHER_VERIFY ?
             -VIRTIO_CRYPTO_KEY_REJECTED : -VIRTIO_CRYPTO_ERR;
@@ -423,6 +423,9 @@ static void cryptodev_lkcf_execute_task(CryptoDevLKCFTask *task)
     }
 
 out:
+    if (local_error) {
+        error_report_err(local_error);
+    }
     if (key_id >= 0) {
         keyctl_unlink(key_id, KCTL_KEY_RING);
     }



  reply	other threads:[~2025-03-12 12:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-12 10:11 [PATCH] cryptodev: Fix error handling in cryptodev_lkcf_execute_task() Markus Armbruster
2025-03-12 10:28 ` zhenwei pi
2025-03-12 12:02   ` Markus Armbruster [this message]
2025-03-14  8:34     ` zhenwei pi
2025-03-18 13:21       ` Markus Armbruster
2025-03-19  2:21         ` zhenwei pi
2025-03-19  5:12           ` Markus Armbruster
2025-03-19  6:29 ` zhenwei pi
2025-03-19  8:37 ` Markus Armbruster

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=87r032ihj2.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=arei.gonglei@huawei.com \
    --cc=pizhenwei@bytedance.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).