[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1808202.Umia7laAZq@silver>
Date: Thu, 07 Dec 2023 13:54:02 +0100
From: Christian Schoenebeck <linux_oss@...debyte.com>
To: Dominique Martinet <asmadeus@...ewreck.org>,
Fedor Pchelkin <pchelkin@...ras.ru>
Cc: Fedor Pchelkin <pchelkin@...ras.ru>,
Eric Van Hensbergen <ericvh@...nel.org>,
Latchesar Ionkov <lucho@...kov.net>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, v9fs@...ts.linux.dev,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Alexey Khoroshilov <khoroshilov@...ras.ru>,
lvc-project@...uxtesting.org
Subject: Re: [PATCH v4] net: 9p: avoid freeing uninit memory in p9pdu_vreadf
On Wednesday, December 6, 2023 9:09:13 PM CET Fedor Pchelkin wrote:
> If some of p9pdu_readf() calls inside case 'T' in p9pdu_vreadf() fails,
> the error path is not handled properly. *wnames or members of *wnames
> array may be left uninitialized and invalidly freed.
>
> Initialize *wnames to NULL in beginning of case 'T'. Initialize the first
> *wnames array element to NULL and nullify the failing *wnames element so
> that the error path freeing loop stops on the first NULL element and
> doesn't proceed further.
>
> Found by Linux Verification Center (linuxtesting.org).
>
> Fixes: ace51c4dd2f9 ("9p: add new protocol support code")
> Signed-off-by: Fedor Pchelkin <pchelkin@...ras.ru>
> ---
> v2: I've missed that *wnames can also be left uninitialized. Please
> ignore the patch v1. As an answer to Dominique's comment: my
> organization marks this statement in all commits.
> v3: Simplify the patch by using kcalloc() instead of array indices
> manipulation per Christian Schoenebeck's remark. Update the commit
> message accordingly.
> v4: Per Christian's suggestion, apply another strategy: mark failing
> array element as NULL and move in the freeing loop until it is found.
> Update the commit message accordingly. If v4 is more appropriate than the
> version at
> https://github.com/martinetd/linux/commit/69cc23eb3a0b79538e9b5face200c4cd5cd32ae0
> then please use it, otherwise, I don't think we can provide more
> convenient solution here than the one already queued at github.
>
> net/9p/protocol.c | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/net/9p/protocol.c b/net/9p/protocol.c
> index 4e3a2a1ffcb3..0e6603b1ec90 100644
> --- a/net/9p/protocol.c
> +++ b/net/9p/protocol.c
> @@ -394,6 +394,8 @@ p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
> uint16_t *nwname = va_arg(ap, uint16_t *);
> char ***wnames = va_arg(ap, char ***);
>
> + *wnames = NULL;
> +
> errcode = p9pdu_readf(pdu, proto_version,
> "w", nwname);
> if (!errcode) {
> @@ -403,6 +405,8 @@ p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
> GFP_NOFS);
> if (!*wnames)
> errcode = -ENOMEM;
> + else
> + (*wnames)[0] = NULL;
> }
>
> if (!errcode) {
> @@ -414,8 +418,10 @@ p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
> proto_version,
> "s",
> &(*wnames)[i]);
> - if (errcode)
> + if (errcode) {
> + (*wnames)[i] = NULL;
> break;
> + }
I just checked whether this could create a leak, but it looks clean, so LGTM:
Reviewed-by: Christian Schoenebeck <linux_oss@...debyte.com>
Dominique, I would tend to use this v4 instead of v2. What do you think?
> }
> }
>
> @@ -423,11 +429,14 @@ p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
> if (*wnames) {
> int i;
>
> - for (i = 0; i < *nwname; i++)
> + for (i = 0; i < *nwname; i++) {
> + if (!(*wnames)[i])
> + break;
> kfree((*wnames)[i]);
> + }
> + kfree(*wnames);
> + *wnames = NULL;
> }
> - kfree(*wnames);
> - *wnames = NULL;
> }
> }
> break;
>
Powered by blists - more mailing lists