LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Jesper Juhl <jj@chaosbits.net>, Milton Miller <miltonm@bga.com>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
Neil Brown <neilb@suse.de>,
bfields@fieldses.org
Subject: Re: [PATCH] Fix size argument to memset call in nfsacl_encode
Date: Thu, 03 Feb 2011 16:55:10 -0500 [thread overview]
Message-ID: <1296770110.12342.6.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <67867FEF-6C10-4A35-8952-4EB56EAB79B9@oracle.com>
On Thu, 2011-02-03 at 15:29 -0500, Chuck Lever wrote:
> Sorry, I wasn't clear. IMO, data that is destined for the network is an important case where we have to be careful about the rule of using either assignments or memset(), not both, when initializing a data structure.
>
> If the compiler doesn't pack the fields in struct posix_acl, there is unused space between them. Memory for acl2 comes from the stack, which contains arbitrary data when this function is invoked. The areas between the structure fields are not affected by the variable assignments used here. If the data in acl2 is then simply memcpy'd to the XDR buffer, that old stack data can possibly appear on the wire.
>
> I agree that the current memset() is incorrect. My conditional ACK was more about what happens in xdr_encode_array2() rather than how the posix_acl acl2 is initialized. I think in that regard we are also safe, if the array encoding operates by data type rather than by simply doing a blanket memcpy. See xdr_nfsace_encode(). It's always possible I misunderstood how ACEs are XDR encoded.
We shouldn't ever be memcopying entire structures directly to or from
the XDR buffer, and as far as I know, the current code will always copy
them element by element.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
next prev parent reply other threads:[~2011-02-03 21:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-03 19:15 Jesper Juhl
2011-02-03 19:28 ` Trond Myklebust
2011-02-03 19:41 ` Jesper Juhl
2011-02-03 20:00 ` Chuck Lever
2011-02-03 20:06 ` Trond Myklebust
2011-02-03 20:29 ` Chuck Lever
2011-02-03 21:55 ` Trond Myklebust [this message]
2011-02-23 22:26 ` Jesper Juhl
2011-02-23 22:27 ` Jesper Juhl
2011-02-04 0:37 ` Milton Miller
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=1296770110.12342.6.camel@heimdal.trondhjem.org \
--to=trond.myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=jj@chaosbits.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=miltonm@bga.com \
--cc=neilb@suse.de \
--subject='Re: [PATCH] Fix size argument to memset call in nfsacl_encode' \
/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
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).