linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Konstantin Khorenko <khorenko@parallels.com>
To: "J. Bruce Fields" <bfields@fieldses.org>, Neil Brown <neilb@suse.de>
Cc: linux-nfs@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [PATCH] NFSD: memory corruption due to writing beyond the stat array
Date: Tue, 01 Feb 2011 17:16:29 +0300	[thread overview]
Message-ID: <4D4815BD.5090404@parallels.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

Hi All,

i've found a bug which makes NFSD to corrupt memory due to writing beyond the stat array.

Initially this issue was found on 2.6.18-x RHEL5 kernel, but the same seems to be true for the current mainstream kernel (checked on 2.6.38-rc3).

./fs/nfsd/vfs.c:
static inline struct raparms *
nfsd_get_raparms(dev_t dev, ino_t ino)
{
...
       // here we searched our file in a readahead cache
       // but not found it
...
         depth = nfsdstats.ra_size*11/10;
...
       // some stuff, but "depth" is not changed
...
         nfsdstats.ra_depth[depth*10/nfsdstats.ra_size]++;
...
}

And here we write to the 12th array element
(nfsdstats.ra_size*11/10*10/nfsdstats.ra_size == 11), while ra_depth has only
11 elements:

struct nfsd_stats {
...
        unsigned int    ra_depth[11];   /* number of times ra entry was found that deep
                                         * in the cache (10percentiles). [10] = not found */
#ifdef CONFIG_NFSD_V4
        unsigned int    nfs4_opcount[LAST_NFS4_OP + 1]; /* count of individual
nfsv4 operations */
#endif
};

This means that each time we did not find a file in a readahead cache we
corrupt memory. Fortunately in a kernel with NFSDv4 compiled in it corrupts
(inc) NFS4 ops counter, but in a kernel with NFSDv4 disabled it corrupts (inc)
some other data, that lays in the memory beyond nfsdstats.

Proposed fix is attached.

--
Best regards,

Konstantin Khorenko

[-- Attachment #2: diff-ms-nfsd-write-beyond-stat-array --]
[-- Type: text/plain, Size: 892 bytes --]

NFSD: The patch fixes writing beyond the array.

If nfsd fails to find an exported via NFS file in the readahead cache,
it should increment corresponding nfsdstats counter (ra_depth[10]), but
due to a bug writes beside the stat array, corrupting following field.

In a kernel with NFSDv4 compiled in it corrupts (inc) NFS4 counter:
the number of individual nfsv4 operations.
In a kernel with NFSDv4 disabled it corrupts (inc) some other data,
that lays in the memory beyond nfsdstats.

Signed-off-by: Konstantin Khorenko <khorenko@openvz.org>

--- a/fs/nfsd/vfs.c.nfsd	2011-01-05 03:50:19.000000000 +0300
+++ b/fs/nfsd/vfs.c	2011-02-01 16:39:28.000000000 +0300
@@ -809,7 +809,7 @@ nfsd_get_raparms(dev_t dev, ino_t ino)
 		if (ra->p_count == 0)
 			frap = rap;
 	}
-	depth = nfsdstats.ra_size*11/10;
+	depth = nfsdstats.ra_size;
 	if (!frap) {	
 		spin_unlock(&rab->pb_lock);
 		return NULL;

             reply	other threads:[~2011-02-01 14:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-01 14:16 Konstantin Khorenko [this message]
2011-02-02 18:19 ` [PATCH] NFSD: memory corruption due to writing beyond the stat array J. Bruce Fields

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=4D4815BD.5090404@parallels.com \
    --to=khorenko@parallels.com \
    --cc=bfields@fieldses.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    /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).