All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: <qemu-devel@nongnu.org>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] tests/9p: fix potential leak in v9fs_rreaddir()
Date: Sat, 29 Apr 2023 14:04:30 +0200	[thread overview]
Message-ID: <20230429140430.05b286a1@bahia> (raw)
In-Reply-To: <E1psh5T-0002XN-1C@lizzy.crudebyte.com>

Hi Christian !

On Sat, 29 Apr 2023 11:25:33 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> Free allocated directory entries in v9fs_rreaddir() if argument
> `entries` was passed as NULL, to avoid a memory leak. It is
> explicitly allowed by design for `entries` to be NULL. [1]
> 
> [1] https://lore.kernel.org/all/1690923.g4PEXVpXuU@silver
> 
> Reported-by: Coverity (CID 1487558)
> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> ---

Good catch Coverity ! :-)

Reviewed-by: Greg Kurz <groug@kaod.org>

I still have a suggestion. See below.

>  tests/qtest/libqos/virtio-9p-client.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/tests/qtest/libqos/virtio-9p-client.c b/tests/qtest/libqos/virtio-9p-client.c
> index e4a368e036..b8adc8d4b9 100644
> --- a/tests/qtest/libqos/virtio-9p-client.c
> +++ b/tests/qtest/libqos/virtio-9p-client.c
> @@ -594,6 +594,8 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t *nentries,
>  {
>      uint32_t local_count;
>      struct V9fsDirent *e = NULL;
> +    /* only used to avoid a leak if entries was NULL */
> +    struct V9fsDirent *unused_entries = NULL;
>      uint16_t slen;
>      uint32_t n = 0;
>  
> @@ -612,6 +614,8 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t *nentries,
>              e = g_new(struct V9fsDirent, 1);
>              if (entries) {
>                  *entries = e;
> +            } else {
> +                unused_entries = e;
>              }
>          } else {
>              e = e->next = g_new(struct V9fsDirent, 1);

This is always allocating and chaining a new entry even
though it isn't needed in the entries == NULL case.

> @@ -628,6 +632,7 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t *nentries,
>          *nentries = n;
>      }
>  
> +    v9fs_free_dirents(unused_entries);

This is going to loop again on all entries to free them.

>      v9fs_req_free(req);
>  }
>  

If this function is to be called one day with an enormous
number of entries and entries == NULL case, this might
not scale well.

What about only allocating a single entry in this case ?

E.g.

@@ -593,7 +593,7 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t *nentries,
                    struct V9fsDirent **entries)
 {
     uint32_t local_count;
-    struct V9fsDirent *e = NULL;
+    g_autofree struct V9fsDirent *e = NULL;
     uint16_t slen;
     uint32_t n = 0;
 
@@ -611,10 +611,12 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t *nentries,
         if (!e) {
             e = g_new(struct V9fsDirent, 1);
             if (entries) {
-                *entries = e;
+                *entries = g_steal_pointer(e);
             }
         } else {
-            e = e->next = g_new(struct V9fsDirent, 1);
+            if (entries) {
+                e = e->next = g_new(struct V9fsDirent, 1);
+            }
         }
         e->next = NULL;
         /* qid[13] offset[8] type[1] name[s] */



  reply	other threads:[~2023-04-29 12:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-29  9:25 [PATCH] tests/9p: fix potential leak in v9fs_rreaddir() Christian Schoenebeck
2023-04-29 12:04 ` Greg Kurz [this message]
2023-04-29 13:20   ` Christian Schoenebeck
2023-05-02  5:46     ` Greg Kurz
2023-05-04 10:53 ` Christian Schoenebeck

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=20230429140430.05b286a1@bahia \
    --to=groug@kaod.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu_oss@crudebyte.com \
    /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.