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 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.