NFSD: memory corruption due to writing beyond the stat array

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

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.

@@ -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;

Actually, I think that's true only if ra_size is divisible by 10; if not, then depth will be something *less* than ra_size*11/10, so depth*10/ra_size will be something less than 11 (namely 10).

... and ra_size is set to 16 * min(2, numthreads/8), so I think you'll hit this only if min(2, numthreads/8) (rounded down) is a multiple of 5? So for example someone using a number of threads that's a power of 2 shouldn't hit this case.

So after the fix: