lkml.org 
[lkml]   [2001]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
Subject[PATCH]drivers/net/wan/lmc/lmc_main.c
From
Hey All,
I am working with Dawson Engler's meta-compillation group @ stanford.
Sorry if this is reposted, previous one seemed to get tied up.
Here is a patch to the drivers/net/wan/lmc/lmc_main.c file.

On line 503, the authors use the GFP_KERNEL argument to kmalloc, how
ever
they are holding a spin lock during this period. They should use
GFP_ATOMIC here.

On line 510, the authors rely on a macro, LMC_COPY_FROM_USER which is
designed to work with stack memory, not heap memory. In all other cases
it is fine, here however, the memory must be deallocated before -EFAULT
can be returned. Note that this is a potential security hole as it is
leaking memory and can be exploited by passing bogus pointers to
copy_to_user - thus creating a DOS situation.

--- drivers/net/wan/lmc/lmc_main.c.orig Thu May 17 12:03:49 2001
+++ drivers/net/wan/lmc/lmc_main.c Mon May 21 20:13:49 2001
@@ -500,14 +500,17 @@
break;
}

- data = kmalloc(xc.len, GFP_KERNEL);
+ data = kmalloc(xc.len, GFP_ATOMIC);
if(data == 0x0){
printk(KERN_WARNING "%s: Failed to allocate memory for copy\n", dev->name);
ret = -ENOMEM;
break;
}

- LMC_COPY_FROM_USER(data, xc.data, xc.len);
+ if(copy_from_user(data, xc.data, xc.len)){
+ kfree(data);
+ return -EFAULT;
+ }

printk("%s: Starting load of data Len: %d at 0x%p == 0x%p\n", dev->name, xc.len, xc.data, data)

Thanks!
-Akash Jain
-
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: 2005-03-22 12:53    [W:0.024 / U:1.128 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site