All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fedor Pchelkin <pchelkin@ispras.ru>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: Dominique Martinet <asmadeus@codewreck.org>,
	 Latchesar Ionkov <lucho@ionkov.net>,
	Eric Van Hensbergen <ericvh@kernel.org>,
	 "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 v2] net: 9p: avoid freeing uninit memory in p9pdu_vreadf
Date: Tue, 5 Dec 2023 16:09:49 +0300	[thread overview]
Message-ID: <9f21f00b-0806-4811-8d0a-9b6175eaedeb-pchelkin@ispras.ru> (raw)
In-Reply-To: <1741521.OAD31uVnNo@silver>

On 23/12/05 01:29PM, Christian Schoenebeck wrote:
> On Tuesday, December 5, 2023 10:19:50 AM CET Fedor Pchelkin wrote:
> > If an error occurs while processing an array of strings in p9pdu_vreadf
> > then uninitialized members of *wnames array are freed.
> > 
> > Fix this by iterating over only lower indices of the array. Also handle
> > possible uninit *wnames usage if first p9pdu_readf() call inside 'T' case
> > fails.
> > 
> > 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.
> > 
> >  net/9p/protocol.c | 12 +++++-------
> >  1 file changed, 5 insertions(+), 7 deletions(-)
> > 
> > diff --git a/net/9p/protocol.c b/net/9p/protocol.c
> > index 4e3a2a1ffcb3..043b621f8b84 100644
> > --- a/net/9p/protocol.c
> > +++ b/net/9p/protocol.c
> > @@ -393,6 +393,8 @@ p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
> >  		case 'T':{
> >  				uint16_t *nwname = va_arg(ap, uint16_t *);
> >  				char ***wnames = va_arg(ap, char ***);
> > +				int i;
> > +				*wnames = NULL;
> 
> Consider also initializing `int i = 0;` here. Because ...
> 

The hassle with indices in this code can be eliminated with using
kcalloc() instead of kmalloc_array(). It would initialize all the members
to zero and later we can use the fact that kfree() is a no-op for NULL
args and iterate over all the elements - this trick is ubiquitous in
kernel AFAIK.

But when trying to do such kind of changes, I wonder whether it would
impact performance (I'm not able to test this fully) or related issues as
for some reason an unsafe kmalloc_array() was originally used.

If you have no objections, then I'll better prepare a new patch with
this in mind. That will make the code less prone to potential errors in
future.

> >  
> >  				errcode = p9pdu_readf(pdu, proto_version,
> >  								"w", nwname);
> > @@ -406,8 +408,6 @@ p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
> >  				}
> >  
> >  				if (!errcode) {
> > -					int i;
> > -
> >  					for (i = 0; i < *nwname; i++) {
> 
> ... this block that initializes `i` is conditional. I mean it does work right
> now as-is, because ...
> 
> >  						errcode =
> >  						    p9pdu_readf(pdu,
> > @@ -421,13 +421,11 @@ p9pdu_vreadf(struct p9_fcall *pdu, int proto_version, const char *fmt,
> >  
> >  				if (errcode) {
> >  					if (*wnames) {
> > -						int i;
> > -
> > -						for (i = 0; i < *nwname; i++)
> > +						while (--i >= 0)
> >  							kfree((*wnames)[i]);
> > +						kfree(*wnames);
> > +						*wnames = NULL;
> >  					}
> 
> ... this is wrapped into `if (*wnames) {` and you initialized *wnames with
> NULL, but it just feels like a potential future trap somehow.
> 
> Anyway, at least it looks like correct behaviour (ATM), so:
> 
> Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
> 
> > -					kfree(*wnames);
> > -					*wnames = NULL;
> >  				}
> >  			}
> >  			break;
> > 
> 
> 

  reply	other threads:[~2023-12-05 13:09 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 [this message]
2023-12-05 18:05         ` [PATCH v3] " Fedor Pchelkin
2023-12-06 13:12           ` Christian Schoenebeck
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=9f21f00b-0806-4811-8d0a-9b6175eaedeb-pchelkin@ispras.ru \
    --to=pchelkin@ispras.ru \
    --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=linux_oss@crudebyte.com \
    --cc=lucho@ionkov.net \
    --cc=lvc-project@linuxtesting.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --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 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.