linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Vitaliy Gusev <gusev.vitaliy@nexenta.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH] nfs4: Fix memory corruption due to not expected FS_LOCATIONS v3
Date: Tue, 22 Mar 2011 17:46:51 -0400	[thread overview]
Message-ID: <1300830411.9442.49.camel@lade.trondhjem.org> (raw)
In-Reply-To: <1300829795-17054-1-git-send-email-gusev.vitaliy@nexenta.com>

On Wed, 2011-03-23 at 00:36 +0300, Vitaliy Gusev wrote:
> Changes with v2 version: when unexpected fs_locations occurs:
> 
> 1. Throw print message "unexpected fs_locations"
> 2. Stop parsing xdr and return EIO error
> 
> ----
> 
> There is a remote vulnerability for nfs4-client. That allows
> a remote NFSv4 server or attacker in middle rewrite memory on
> NFSv4 client.
> Of course if encryption is used then only server can do corruption.
> 
> 1. Client send GETATTR request to server, but there are not
>    checks for bitmask in reply from server. Therefore server may return
>    more attributes than were asked.
> 
> 2. Pointer to struct nfs_fattr is passed to decode_getfattr(), but
>    that parameter is considered as pointer to struct nfs4_fs_locations
>    in case set FATTR4_WORD0_FS_LOCATIONS in reply from server.
> 
>    But there is no check for pointer type that was passed!
> 
> 3. Remote side can set FATTR4_WORD0_FS_LOCATIONS and fill
>    datas fsattr4_fs_locations in reply to client.
> 
> 4. sizeof(nfs4_fs_locations) is about 92080 bytes in kernel 2.6.38
> 
>    So ~ 90 Kbytes can be overwritten in memory of NFSv4 client.
> 
>    Fortunately, nfs_fattr is allocated via kmalloc and
>    is not stored on stack. So generally kmalloc-192 is corrupted.
> 
>    Affected kernels: all from v2.6.18
>    Commit 683b57b435326eb512c7305892683b6205669448
>    "NFSv4: Implement the fs_locations function call"
> ---
>  fs/nfs/nfs4xdr.c |   39 +++++++++++++++++++++++++++++----------
>  1 files changed, 29 insertions(+), 10 deletions(-)
> 
> diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
> index c87e543..6fea9c9 100644
> --- a/fs/nfs/nfs4xdr.c
> +++ b/fs/nfs/nfs4xdr.c
> @@ -3451,7 +3451,8 @@ out_overflow:
>  	return -EIO;
>  }
>  
> -static int decode_attr_fs_locations(struct xdr_stream *xdr, uint32_t *bitmap, struct nfs4_fs_locations *res)
> +static int decode_attr_fs_locations(struct xdr_stream *xdr, uint32_t *bitmap, struct nfs4_fs_locations *res,
> +				    uint32_t *deny_bitmap)
>  {
>  	int n;
>  	__be32 *p;
> @@ -3462,6 +3463,13 @@ static int decode_attr_fs_locations(struct xdr_stream *xdr, uint32_t *bitmap, st
>  	status = 0;
>  	if (unlikely(!(bitmap[0] & FATTR4_WORD0_FS_LOCATIONS)))
>  		goto out;
> +
> +	if (unlikely(deny_bitmap[0] & FATTR4_WORD0_FS_LOCATIONS)) {
> +		status = -EIO;
> +		printk(KERN_WARNING "%s: Unexpected fs_locations\n", __func__);
> +		goto out;
> +	}

Why are you limiting this to fs_locations? As I believe I said earlier,
any attribute that we didn't explicitly request is an error and can
cause corruption in the client.

If we're going to fix this, we should fix all potential occurrences once
and for all.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com


  reply	other threads:[~2011-03-22 21:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-22 21:36 [PATCH] nfs4: Fix memory corruption due to not expected FS_LOCATIONS v3 Vitaliy Gusev
2011-03-22 21:46 ` Trond Myklebust [this message]
2011-03-22 22:39   ` Vitaliy Gusev
2011-03-22 23:10     ` Trond Myklebust
2011-03-22 23:18       ` Vitaliy Gusev

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=1300830411.9442.49.camel@lade.trondhjem.org \
    --to=trond.myklebust@netapp.com \
    --cc=gusev.vitaliy@nexenta.com \
    --cc=linux-nfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).