lkml.org 
[lkml]   [2006]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[PATCH] fdtable: Eradicate fdarray overflow.
Date
Andrew,

If you want it, here is the "actual patch format" fix for the random kernel
bug issue that has been discovered. This patch is functionally identical to
the one you grabbed, but contains comments and sign-offs.

Fix the computation of the length of an allocated fdarray, when we decide to
grow the fdtable. The rationale behind this fix is as follows:
=> The 'nr' variable is the requested fd, so will be one less than the minimum
allowable fdarray size.
=> Due to the above fact, when we divide 'nr' by a fourth-of-a-page block, we
will always be exactly one block short of the size we need.
=> Incrementing before the division is wrong, because the division will discard
a non-zero modulo, possibly leaving us one fourth-of-a-page block short.

Signed-off-by: Vadim Lobanov <vlobanov@speakeasy.net>

diff -Npru old/fs/file.c new/fs/file.c
--- old/fs/file.c 2006-10-10 18:58:21.000000000 -0700
+++ new/fs/file.c 2006-10-11 19:37:23.000000000 -0700
@@ -164,9 +164,8 @@ static struct fdtable * alloc_fdtable(un
* the fdarray into page-sized chunks: starting at a quarter of a page,
* and growing in powers of two from there on.
*/
- nr++;
nr /= (PAGE_SIZE / 4 / sizeof(struct file *));
- nr = roundup_pow_of_two(nr);
+ nr = roundup_pow_of_two(nr + 1);
nr *= (PAGE_SIZE / 4 / sizeof(struct file *));
if (nr > NR_OPEN)
nr = NR_OPEN;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
\
 
 \ /
  Last update: 2006-10-12 05:01    [W:0.053 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site