All of lore.kernel.org
 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 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.