Jes Sorensen wrote:
> I assume you mean select().
>
> Updated patch attached.
This fixes a few problems introduced by this patch.
* Fixes two warnings caused by mixing "char *" and "long *" pointers
* If SELECT_STACK_ALLOC is not a multiple of sizeof(long) then stack_fds[]
would be less than SELECT_STACK_ALLOC bytes and could overflow later in
the function. Fixed by simply rearranging the test later to work on
sizeof(stack_fds)
Currently SELECT_STACK_ALLOC is 256 so this doesn't happen, but it's
nasty to have things like this hidden in the code. What if later
someone decides to change SELECT_STACK_ALLOC to 300?
* I also changed "size" to be unsigned since that makes more sense and
is less prone to overflow bugs. I'm also a little scared by the
"kmalloc(6 * size)" since that type of call is a classic multiply-overflow
security hole (hence libc's calloc() API). However "size" is constrained
by fdt->max_fdset so I think it isn't exploitable. The kernel doesn't
have an overflow-safe API for kmalloc'ing arrays, does it?
Patch is vs current git HEAD. Only compile/boot tested.
Signed-off-by: Mitchell Blank Jr <[email protected]>
diff --git a/fs/select.c b/fs/select.c
index 071660f..bd9c7db 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -311,7 +311,8 @@ static int core_sys_select(int n, fd_set
{
fd_set_bits fds;
char *bits;
- int ret, size, max_fdset;
+ int ret, max_fdset;
+ unsigned int size;
struct fdtable *fdt;
/* Allocate small arguments on the stack to save memory and be faster */
long stack_fds[SELECT_STACK_ALLOC/sizeof(long)];
@@ -335,8 +336,8 @@ static int core_sys_select(int n, fd_set
*/
ret = -ENOMEM;
size = FDS_BYTES(n);
- if (6*size < SELECT_STACK_ALLOC)
- bits = stack_fds;
+ if (size < sizeof(stack_fds) / 6)
+ bits = (char *) stack_fds;
else
bits = kmalloc(6 * size, GFP_KERNEL);
if (!bits)
@@ -373,7 +374,7 @@ static int core_sys_select(int n, fd_set
ret = -EFAULT;
out:
- if (bits != stack_fds)
+ if (bits != (char *) stack_fds)
kfree(bits);
out_nofds:
return ret;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]