From: Kees Cook <keescook@chromium.org>
To: Anna Schumaker <anna@kernel.org>
Cc: Trond Myklebust <trondmy@hammerspace.com>,
kernel test robot <yujie.liu@intel.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Dave Jones <davej@codemonkey.org.uk>,
Bagas Sanjaya <bagasdotme@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-hardening@vger.kernel.org"
<linux-hardening@vger.kernel.org>
Subject: Re: [PATCH v2] NFS: Avoid memcpy() run-time warning for struct sockaddr overflows
Date: Wed, 26 Oct 2022 17:26:58 -0700 [thread overview]
Message-ID: <202210261726.554CBDC55@keescook> (raw)
In-Reply-To: <35A4B422-29FF-4294-8596-D75FC60E55DE@hammerspace.com>
On Thu, Oct 27, 2022 at 12:03:07AM +0000, Trond Myklebust wrote:
>
>
> > On Oct 26, 2022, at 19:32, Kees Cook <keescook@chromium.org> wrote:
> >
> > On Sun, Oct 16, 2022 at 09:36:50PM -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'. Plumb the use of 'struct sockaddr_storage' more
> >> completely through-out NFS, which results in adjusting the memcpy()
> >> buffers to the correct union members. 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>
> >
> > Friendly ping -- this needs to land in v6.1 to avoid these warnings.
> > Should I carry this in the hardening tree instead?
> >
> > Thanks!
>
> Anna, this is your call since you’re the ‘6.1 nfs client maintainer’...
And just to remind, this came up in -rc1 as well:
https://lore.kernel.org/lkml/202210162144.76FBC7271@keescook/
--
Kees Cook
next prev parent reply other threads:[~2022-10-27 0:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-17 4:36 [PATCH v2] NFS: Avoid memcpy() run-time warning for struct sockaddr overflows Kees Cook
2022-10-26 23:32 ` Kees Cook
2022-10-27 0:03 ` Trond Myklebust
2022-10-27 0:26 ` Kees Cook [this message]
2022-11-02 15:51 ` Petr Vorel
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=202210261726.554CBDC55@keescook \
--to=keescook@chromium.org \
--cc=anna@kernel.org \
--cc=bagasdotme@gmail.com \
--cc=davej@codemonkey.org.uk \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@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.