All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	"kernel-janitors@vger.kernel.org"
	<kernel-janitors@vger.kernel.org>,
	Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Subject: Re: [PATCH] NFSD: check for negative "len" values in nfssvc_decode_writeargs()
Date: Tue, 15 Mar 2022 12:45:08 +0300	[thread overview]
Message-ID: <20220315094507.GW3315@kadam> (raw)
In-Reply-To: <6F04F280-5267-4D12-8053-2074703DBE6B@oracle.com>

On Mon, Mar 14, 2022 at 05:42:58PM +0300, Chuck Lever III wrote:
> Hi Dan-
> 
> > On Mar 14, 2022, at 10:06 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > 
> > This code checks the upper bound of "len" but it needs to check for
> > negative values as well.
> 
> It doesn't check because nfsd3_writeargs::len is a __u32,
> and the NFSv2 code here was copied from that assuming that
> nfsd_writeargs::len had the same signage. This is because...
> 
> https://datatracker.ietf.org/doc/html/rfc1832#section-3.13 says
> that the count field in a variable-length array is supposed to
> be unsigned.
> 
> Thus IMO nfsd_writeargs::len should be changed to __u32
> instead of adding the extra negativity check.
> 
> If you resend, make sure the format specifier in the dprintk()
> at the top of nfsd_proc_write() is adjusted accordingly.

Thanks for this tip.  It's weird that GCC doesn't complain if you don't
make this change to the printk.  :/

regards,
dan carpenter


      reply	other threads:[~2022-03-15  9:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-14 14:06 [PATCH] NFSD: check for negative "len" values in nfssvc_decode_writeargs() Dan Carpenter
2022-03-14 14:42 ` Chuck Lever III
2022-03-15  9:45   ` Dan Carpenter [this message]

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=20220315094507.GW3315@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=chuck.lever@oracle.com \
    --cc=harshit.m.mogalapalli@oracle.com \
    --cc=kernel-janitors@vger.kernel.org \
    --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 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.