* [PATCH] tests/9p: fix potential leak in v9fs_rreaddir()
@ 2023-04-29 9:25 Christian Schoenebeck
2023-04-29 12:04 ` Greg Kurz
2023-05-04 10:53 ` Christian Schoenebeck
0 siblings, 2 replies; 5+ messages in thread
From: Christian Schoenebeck @ 2023-04-29 9:25 UTC (permalink / raw)
To: qemu-devel; +Cc: Greg Kurz, Paolo Bonzini
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>
---
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);
@@ -628,6 +632,7 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t *nentries,
*nentries = n;
}
+ v9fs_free_dirents(unused_entries);
v9fs_req_free(req);
}
--
2.30.2
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] tests/9p: fix potential leak in v9fs_rreaddir()
2023-04-29 9:25 [PATCH] tests/9p: fix potential leak in v9fs_rreaddir() Christian Schoenebeck
@ 2023-04-29 12:04 ` Greg Kurz
2023-04-29 13:20 ` Christian Schoenebeck
2023-05-04 10:53 ` Christian Schoenebeck
1 sibling, 1 reply; 5+ messages in thread
From: Greg Kurz @ 2023-04-29 12:04 UTC (permalink / raw)
To: Christian Schoenebeck; +Cc: qemu-devel, Paolo Bonzini
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] */
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] tests/9p: fix potential leak in v9fs_rreaddir()
2023-04-29 12:04 ` Greg Kurz
@ 2023-04-29 13:20 ` Christian Schoenebeck
2023-05-02 5:46 ` Greg Kurz
0 siblings, 1 reply; 5+ messages in thread
From: Christian Schoenebeck @ 2023-04-29 13:20 UTC (permalink / raw)
To: qemu-devel; +Cc: Paolo Bonzini, Greg Kurz
On Saturday, April 29, 2023 2:04:30 PM CEST Greg Kurz wrote:
> Hi Christian !
Hi there, it's been a while! :)
> 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 ! :-)
Yeah, this Coverity report is actually from March and I ignored it so far,
because the reported leak could never happen with current test code. But Paolo
brought it up this week, so ...
> 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);
g_steal_pointer(e) just sets `e` to NULL and returns its old value, so ...
> }
> } else {
> - e = e->next = g_new(struct V9fsDirent, 1);
> + if (entries) {
> + e = e->next = g_new(struct V9fsDirent, 1);
> + }
... this `else` block would never be reached and no list assembled.
> }
> e->next = NULL;
> /* qid[13] offset[8] type[1] name[s] */
And even if above's issue was fixed, then it would cause a use-after-free for
the last element in the list if entries != NULL and caller trying to access
the last element afterwards. So you would still need a separate g_autofree
pointer instead of tagging `e` directly, or something like this after loop
end:
if (entries)
g_steal_pointer(e);
Which would somehow defeat the purpose of using g_autofree though.
I mean, yes this could be addressed, but is it worth it? I don't know. Even
this reported leak is a purely theoretical one, but I understand if people
want to silence a warning.
Best regards,
Christian Schoenebeck
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] tests/9p: fix potential leak in v9fs_rreaddir()
2023-04-29 13:20 ` Christian Schoenebeck
@ 2023-05-02 5:46 ` Greg Kurz
0 siblings, 0 replies; 5+ messages in thread
From: Greg Kurz @ 2023-05-02 5:46 UTC (permalink / raw)
To: Christian Schoenebeck; +Cc: qemu-devel, Paolo Bonzini
On Sat, 29 Apr 2023 15:20:12 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> On Saturday, April 29, 2023 2:04:30 PM CEST Greg Kurz wrote:
> > Hi Christian !
>
> Hi there, it's been a while! :)
>
> > 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 ! :-)
>
> Yeah, this Coverity report is actually from March and I ignored it so far,
> because the reported leak could never happen with current test code. But Paolo
> brought it up this week, so ...
>
> > 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);
>
> g_steal_pointer(e) just sets `e` to NULL and returns its old value, so ...
>
> > }
> > } else {
> > - e = e->next = g_new(struct V9fsDirent, 1);
> > + if (entries) {
> > + e = e->next = g_new(struct V9fsDirent, 1);
> > + }
>
> ... this `else` block would never be reached and no list assembled.
>
> > }
> > e->next = NULL;
> > /* qid[13] offset[8] type[1] name[s] */
>
> And even if above's issue was fixed, then it would cause a use-after-free for
> the last element in the list if entries != NULL and caller trying to access
> the last element afterwards. So you would still need a separate g_autofree
> pointer instead of tagging `e` directly, or something like this after loop
> end:
>
> if (entries)
> g_steal_pointer(e);
>
> Which would somehow defeat the purpose of using g_autofree though.
>
> I mean, yes this could be addressed, but is it worth it? I don't know. Even
> this reported leak is a purely theoretical one, but I understand if people
> want to silence a warning.
>
Yeah you're right.
Cheers,
--
Greg
> Best regards,
> Christian Schoenebeck
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] tests/9p: fix potential leak in v9fs_rreaddir()
2023-04-29 9:25 [PATCH] tests/9p: fix potential leak in v9fs_rreaddir() Christian Schoenebeck
2023-04-29 12:04 ` Greg Kurz
@ 2023-05-04 10:53 ` Christian Schoenebeck
1 sibling, 0 replies; 5+ messages in thread
From: Christian Schoenebeck @ 2023-05-04 10:53 UTC (permalink / raw)
To: qemu-devel; +Cc: Greg Kurz, Paolo Bonzini
On Saturday, April 29, 2023 11:25:33 AM CEST Christian Schoenebeck 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>
> ---
Queued on 9p.next:
https://github.com/cschoenebeck/qemu/commits/9p.next
Thanks!
Best regards,
Christian Schoenebeck
> 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);
> @@ -628,6 +632,7 @@ void v9fs_rreaddir(P9Req *req, uint32_t *count, uint32_t *nentries,
> *nentries = n;
> }
>
> + v9fs_free_dirents(unused_entries);
> v9fs_req_free(req);
> }
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-05-04 10:53 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-04-29 9:25 [PATCH] tests/9p: fix potential leak in v9fs_rreaddir() Christian Schoenebeck
2023-04-29 12:04 ` Greg Kurz
2023-04-29 13:20 ` Christian Schoenebeck
2023-05-02 5:46 ` Greg Kurz
2023-05-04 10:53 ` Christian Schoenebeck
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).