linux-hardening - Re: [PATCH] NFS: Avoid memcpy() run-time warning for struct sockaddr overflows

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 11 Oct 2022 09:38:14 -0700
From:   Kees Cook <keescook@...omium.org>
To:     "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Trond Myklebust <trond.myklebust@...merspace.com>
Cc:     kernel test robot <yujie.liu@...el.com>,
        Anna Schumaker <anna@...nel.org>, linux-nfs@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] NFS: Avoid memcpy() run-time warning for struct sockaddr
 overflows

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@...el.com>
> > Link: https://lore.kernel.org/all/202210110948.26b43120-yujie.liu@intel.com
> > Cc: Trond Myklebust <trond.myklebust@...merspace.com>
> > Cc: Anna Schumaker <anna@...nel.org>
> > Cc: linux-nfs@...r.kernel.org
> > Signed-off-by: Kees Cook <keescook@...omium.org>
> 
> Reviewed-by: Gustavo A. R. Silva <gustavoars@...nel.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