From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B21D6C77B7C for ; Sat, 29 Apr 2023 13:21:24 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pskUy-0006F7-Nq; Sat, 29 Apr 2023 09:20:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pskUu-0006Ee-H4 for qemu-devel@nongnu.org; Sat, 29 Apr 2023 09:20:21 -0400 Received: from kylie.crudebyte.com ([5.189.157.229]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pskUs-0008Ag-Ci for qemu-devel@nongnu.org; Sat, 29 Apr 2023 09:20:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crudebyte.com; s=kylie; h=Content-Type:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Content-ID:Content-Description; bh=hcVHp/MqBrwV+AQ22tTDRGes1ucmsRTCfVefJMw46q4=; b=XZxsE8oh6IthoXJfbpXFkx5uu0 zwb/QPwWufPzD1iafaJ7DVylU2TXFWrnePQT0M2wHJhH1R2z6z90xmi/FBf+carhc0+x+kf7yzSHW Jg/sP/Edk4g4IHdnJN6ClITTyCC4a3XzfC8XoZz0/tePOOEIgFRvVe0bHqnhWMrXQ5yInMHdGLrMV YXBYPEbb09o4c9rWMHU7YRZ8eK4NIS+rfi3t2SLtYbUlJIO+fpt1NTCDDGKpDBVvCYkF9Yap2mVV5 H5ZysM6Z+e54U74LKJ4DmhuLc4AoETf/hwthn3O9Nbjhu5ie7citN17FXjs6XFzIoYWeGHyvJudko L3t8/JEy6kD1FdX4HKAdA6wGKeo3JfGnz3JcEHsQLELd1lD0ZAaDUYzZojww9UeHoKtmIDFrcKwJw 66F0QWO9Qcl0BuBbTGKnjhY70g3BeQTBpTHCuzY5fIqrJJ02q/1e+q9YNZ+Mnd5mrKTX6cAp3VZAu oMmd9IpwxFRG9nT9QOffKI7Ih2H9KmXovzwlE3CEe8CKCKU6Zfe9aX+m3TouXpKTFh3xtgsea9cTK 3Xl+HgUw1ISXoG57j96Wl+kAcD/DHAyf64RDVGcLluutHrExFwSljB8KQxEbb3hRcEFC4BbOFFjYH 4FDAGoVzmM+9qT5nnCXZkZKwHh9Y8VlqlIBYGnaZo=; From: Christian Schoenebeck To: qemu-devel@nongnu.org Cc: Paolo Bonzini , Greg Kurz Subject: Re: [PATCH] tests/9p: fix potential leak in v9fs_rreaddir() Date: Sat, 29 Apr 2023 15:20:12 +0200 Message-ID: <2011937.24IBG10sf5@silver> In-Reply-To: <20230429140430.05b286a1@bahia> References: <20230429140430.05b286a1@bahia> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: pass client-ip=5.189.157.229; envelope-from=qemu_oss@crudebyte.com; helo=kylie.crudebyte.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org 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 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 > > --- > > 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 > > 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