From: Kees Cook <keescook@chromium.org>
To: "Gustavo A. R. Silva" <gustavoars@kernel.org>,
Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: kernel test robot <yujie.liu@intel.com>,
Anna Schumaker <anna@kernel.org>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH] NFS: Avoid memcpy() run-time warning for struct sockaddr overflows
Date: Tue, 11 Oct 2022 09:38:14 -0700 [thread overview]
Message-ID: <202210110934.AA4F52C77@keescook> (raw)
In-Reply-To: <Y0WK3MZvxpoXS24n@work>
On Tue, Oct 11, 2022 at 10:25:16AM -0500, Gustavo A. R. Silva wrote:
> On Mon, Oct 10, 2022 at 11:52:43PM -0700, Kees Cook wrote:
> > The 'nfs_server' and 'mount_server' structures include a union of
> > 'struct sockaddr' (with the older 16 bytes max address size) and
> > 'struct sockaddr_storage' which is large enough to hold all the supported
> > sa_family types (128 bytes max size). The runtime memcpy() buffer overflow
> > checker is seeing attempts to write beyond the 16 bytes as an overflow,
> > but the actual expected size is that of 'struct sockaddr_storage'. Adjust
> > the pointers to the correct union member. Avoids this false positive
> > run-time warning under CONFIG_FORTIFY_SOURCE:
> >
> > memcpy: detected field-spanning write (size 28) of single field "&ctx->nfs_server.address" at fs/nfs/namespace.c:178 (size 16)
> >
> > Reported-by: kernel test robot <yujie.liu@intel.com>
> > Link: https://lore.kernel.org/all/202210110948.26b43120-yujie.liu@intel.com
> > Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
> > Cc: Anna Schumaker <anna@kernel.org>
> > Cc: linux-nfs@vger.kernel.org
> > Signed-off-by: Kees Cook <keescook@chromium.org>
>
> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Thanks!
> > ---
> > fs/nfs/fs_context.c | 2 +-
> > fs/nfs/namespace.c | 2 +-
> > fs/nfs/super.c | 4 ++--
> > 3 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/fs/nfs/fs_context.c b/fs/nfs/fs_context.c
> > index 4da701fd1424..bffa31bb35b9 100644
> > --- a/fs/nfs/fs_context.c
> > +++ b/fs/nfs/fs_context.c
> > @@ -1540,7 +1540,7 @@ static int nfs_init_fs_context(struct fs_context *fc)
> > ctx->version = nfss->nfs_client->rpc_ops->version;
> > ctx->minorversion = nfss->nfs_client->cl_minorversion;
> >
> > - memcpy(&ctx->nfs_server.address, &nfss->nfs_client->cl_addr,
> > + memcpy(&ctx->nfs_server._address, &nfss->nfs_client->cl_addr,
> > ctx->nfs_server.addrlen);
So, I spent a bunch more time looking at the plumbing of struct sockaddr
vs struct sockaddr_storage. In NFS, everything I could find is actually
already backed by a full sockaddr_storage, so I think a more complete
fix here would actually be to update all the internals to pass
sockaddr_storage instead of sockaddr. The interfaces to other things
(e.g. rpc) can cast back to sockaddr for now. It is a pretty reasonable
cleanup, IMO.
I'll send a follow-up that makes this change on top of this patch,
though they could be squashed if that was desired.
--
Kees Cook
prev parent reply other threads:[~2022-10-11 16:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-11 6:52 [PATCH] NFS: Avoid memcpy() run-time warning for struct sockaddr overflows Kees Cook
2022-10-11 15:25 ` Gustavo A. R. Silva
2022-10-11 16:38 ` Kees Cook [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=202210110934.AA4F52C77@keescook \
--to=keescook@chromium.org \
--cc=anna@kernel.org \
--cc=gustavoars@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@hammerspace.com \
--cc=yujie.liu@intel.com \
/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