netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: Dominique Martinet <asmadeus@codewreck.org>,
	Fedor Pchelkin <pchelkin@ispras.ru>
Cc: Fedor Pchelkin <pchelkin@ispras.ru>,
	Eric Van Hensbergen <ericvh@kernel.org>,
	Latchesar Ionkov <lucho@ionkov.net>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	v9fs@lists.linux.dev, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Alexey Khoroshilov <khoroshilov@ispras.ru>,
	lvc-project@linuxtesting.org
Subject: Re: [PATCH v3] net: 9p: avoid freeing uninit memory in p9pdu_vreadf
Date: Wed, 06 Dec 2023 14:12:37 +0100	[thread overview]
Message-ID: <10981267.HhOBSzzNiN@silver> (raw)
In-Reply-To: <20231205180523.11318-1-pchelkin@ispras.ru>

On Tuesday, December 5, 2023 7:05:22 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.
> 
> In order not to complicate the code with array index processing, fix the
> problem with initializing *wnames to NULL in beginning of case 'T' and
> using kcalloc() to allocate and initialize the array. For assurance,
> nullify the failing *wnames element (the callee handles that already -
> e.g. see 's' case).
> 
> Found by Linux Verification Center (linuxtesting.org).
> 
> Fixes: ace51c4dd2f9 ("9p: add new protocol support code")
> Signed-off-by: Fedor Pchelkin <pchelkin@ispras.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.
> 
>  net/9p/protocol.c | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/net/9p/protocol.c b/net/9p/protocol.c
> index 4e3a2a1ffcb3..7067fb49d713 100644
> --- a/net/9p/protocol.c
> +++ b/net/9p/protocol.c
> @@ -394,13 +394,14 @@ 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) {
>  					*wnames =
> -					    kmalloc_array(*nwname,
> -							  sizeof(char *),
> -							  GFP_NOFS);
> +					    kcalloc(*nwname, sizeof(char *),
> +						    GFP_NOFS);

Context of this code is transmitting directory entries, e.g. thousands of
array elements. So this would always introduce performance costs. The error
cases this patch addresses should happen rather rarely BTW.

Another option (instead of clearing the entire array) would be just setting
the last entry in the array to NULL, and the loop freeing the elements would
stop at the first NULL entry. That way you don't have to worry about carrying
`i` along and `i` being correctly intitalized. Would require array size +1
though.

In general I agree that this code section calls out to be simplified, but I
doubt that clearing the entire array is the best way to go here.

>  					if (!*wnames)
>  						errcode = -ENOMEM;
>  				}
> @@ -414,8 +415,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;
> +						}
>  					}
>  				}
>  
> @@ -425,9 +428,9 @@ p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
>  
>  						for (i = 0; i < *nwname; i++)
>  							kfree((*wnames)[i]);
> +						kfree(*wnames);
> +						*wnames = NULL;
>  					}
> -					kfree(*wnames);
> -					*wnames = NULL;
>  				}
>  			}
>  			break;
> 





  reply	other threads:[~2023-12-06 13:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-05  8:05 [PATCH] net: 9p: avoid freeing uninit memory in p9pdu_vreadf Fedor Pchelkin
2023-12-05  9:07 ` Dominique Martinet
2023-12-05  9:19   ` [PATCH v2] " Fedor Pchelkin
2023-12-05  9:31     ` Dominique Martinet
2023-12-05 12:15       ` Fedor Pchelkin
2023-12-05 12:43         ` Dominique Martinet
2023-12-05 12:29     ` Christian Schoenebeck
2023-12-05 13:09       ` Fedor Pchelkin
2023-12-05 18:05         ` [PATCH v3] " Fedor Pchelkin
2023-12-06 13:12           ` Christian Schoenebeck [this message]
2023-12-06 20:09             ` [PATCH v4] " Fedor Pchelkin
2023-12-07 12:54               ` Christian Schoenebeck
2023-12-11 23:21                 ` Dominique Martinet
2024-01-07  7:56                   ` Vitaly Chikunov
2024-01-07  9:48                     ` Fedor Pchelkin
2024-01-07 10:14                       ` Vitaly Chikunov
2024-01-07 10:26                     ` Dominique Martinet
2023-12-11 13:51               ` Simon Horman

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=10981267.HhOBSzzNiN@silver \
    --to=linux_oss@crudebyte.com \
    --cc=asmadeus@codewreck.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=ericvh@kernel.org \
    --cc=khoroshilov@ispras.ru \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=lvc-project@linuxtesting.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pchelkin@ispras.ru \
    --cc=v9fs@lists.linux.dev \
    /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).