Linux NFS development
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@poochiereds.net>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: knfsd: clean up nfsd filesystem interfaces
Date: Sat, 22 Aug 2015 18:56:18 -0400	[thread overview]
Message-ID: <20150822185618.41d20096@tlielax.poochiereds.net> (raw)
In-Reply-To: <20150822195814.GA20768@mwanda>

On Sat, 22 Aug 2015 22:58:14 +0300
Dan Carpenter <dan.carpenter@oracle.com> wrote:

> Hello Jeff Layton,
> 
> The patch 3dd98a3bccb1: "knfsd: clean up nfsd filesystem interfaces"
> from Jun 10, 2008, leads to the following static checker warning:
> 
> 	fs/nfsd/nfsctl.c:1030 __write_recoverydir()
> 	error: buffer overflow 'buf' 4088 <= 4095
> 
> fs/nfsd/nfsctl.c
>   1020  static ssize_t __write_recoverydir(struct file *file, char *buf, size_t size,
>   1021                                     struct nfsd_net *nn)
>   1022  {
>   1023          char *mesg = buf;
>   1024          char *recdir;
>   1025          int len, status;
>   1026  
>   1027          if (size > 0) {
>   1028                  if (nn->nfsd_serv)
>   1029                          return -EBUSY;
>   1030                  if (size > PATH_MAX || buf[size-1] != '\n')
> 
> This test is wrong.  simple_transaction_get() doesn't return a PAGE_SIZE
> buf.  On the other hand, it's harmless because simple_transaction_get()
> has it's own limit check.
> 
> 
> I feel like the limit check in simple_transaction_get() is one char
> too restrictive.  Maybe the simple_transaction_argresp struct used to
> have a data[1] back before we had git?
> 
> 
> Anyway, we could either delete this check or change it to:
> 
> 		if (size > SIMPLE_TRANSACTION_LIMIT || buf[size-1] != '\n')
> 

(Note that I'm no longer at Red Hat, so jlayton@redhat.com will
probably bounce...)

Hmmm...is that the case on all arches though? What if PAGE_SIZE is >4k?

    #define PATH_MAX 4096

...and...

    #define SIMPLE_TRANSACTION_LIMIT (PAGE_SIZE - sizeof(struct simple_transaction_argresp))

If PAGE_SIZE > 4096, then we could still end up with a pathname that
is longer than we can actually use in that situation.

I think we need to keep that check there (or something like it), even if
just to future-proof this code. But, I am open to suggestions on ways to
make the static checker happy.

>   1031                          return -EINVAL;
>   1032                  buf[size-1] = 0;
>   1033  
>   1034                  recdir = mesg;
>   1035                  len = qword_get(&mesg, recdir, size);
>   1036                  if (len <= 0)
>   1037                          return -EINVAL;
>   1038  
>   1039                  status = nfs4_reset_recoverydir(recdir);
>   1040                  if (status)
>   1041                          return status;
>   1042          }
>   1043  
>   1044          return scnprintf(buf, SIMPLE_TRANSACTION_LIMIT, "%s\n",
>   1045                                                          nfs4_recoverydir());
>   1046  }
> 
> regards,
> dan carpenter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Jeff Layton <jlayton@poochiereds.net>

  reply	other threads:[~2015-08-22 22:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-22 19:58 knfsd: clean up nfsd filesystem interfaces Dan Carpenter
2015-08-22 22:56 ` Jeff Layton [this message]
2015-08-25  6:03   ` Dan Carpenter

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=20150822185618.41d20096@tlielax.poochiereds.net \
    --to=jlayton@poochiereds.net \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /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