Bug 69941

Summary: Unsafe dynamic memory allocation using kmalloc
Product: Other Reporter: Jonathan Boyd (jboyd)
Component: OtherAssignee: other_other
Status: RESOLVED INVALID    
Severity: normal CC: alan
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.14-rc1 Subsystem:
Regression: No Bisected commit-id:

Description Jonathan Boyd 2014-02-04 00:49:52 UTC
Consider the following code:
X * p = kmalloc(sizeof(X), GFP_KERNEL);
p->x = 42;

vs

X * p = kmalloc(sizeof(X), GFP_KERNEL);
if(p) {
 p->x = 42;
}

if "kmalloc" were to return "NULL" this would write "42" to NULL+the offset in X of "x"...probably something like null+4. Running in kernel mode in low resource conditions this could result in a kernel panic or an otherwise unstable system.

It is generally considered best practice to test for NULL before dereferencing dynamically allocated memory. While auditing linux codes, the following examples of unsafe dynamic memory allocation using kmalloc were discovered.

C:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\arch\arm\mach-u300\dummyspichip.c:64 	bigrxbuf_virtual = kmalloc(DMA_TEST_SIZE, GFP_KERNEL);
C:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\arch\cris\arch-v32\kernel\signal.c:543 	u16* data = kmalloc(PAGE_SIZE, GFP_KERNEL);
C:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\arch\cris\arch-v32\mm\intmem.c:75 					tmp = kmalloc(sizeof *tmp, GFP_ATOMIC);
C:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\arch\x86\platform\efi\efi_64.c:92 	save_pgd = kmalloc(n_pgds * sizeof(pgd_t), GFP_KERNEL);
C:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\arch\x86\platform\uv\tlb_uv.c:2078 	vp = kmalloc(nuvhubs * sizeof(struct uvhub_desc), GFP_KERNEL);
c:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\drivers\misc\lkdtm.c : 383 		u32 *data = kmalloc(len, GFP_KERNEL);
c:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\drivers\parisc\ccio-dma.c : 1408 	char *name = kmalloc(14, GFP_KERNEL);
c:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\drivers\pci\msi.c : 546 		char *name = kmalloc(20, GFP_KERNEL);
c:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\drivers\staging\et131x\et131x.c : 2125 	rx_ring->fbr[0] = kmalloc(sizeof(struct fbr_lookup), GFP_KERNEL);
c:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\drivers\staging\et131x\et131x.c : 2126 	rx_ring->fbr[1] = kmalloc(sizeof(struct fbr_lookup), GFP_KERNEL);
c:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\drivers\staging\ft1000\ft1000-usb\ft1000_hw.c : 332 	commandbuf = kmalloc(size + 2, GFP_KERNEL);
c:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\drivers\staging\netlogic\xlr_net.c : 893 	priv->mii_bus->irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
c:\me\src\linux-3.14-rc1.tar\linux-3.14-rc1\linux-3.14-rc1\fs\ceph\export.c : 187 		req->r_path2 = kmalloc(16, GFP_NOFS);
Comment 1 Alan 2014-02-04 11:18:06 UTC
This bug report makes almost no sense because you've not looked at the context of whatever your test tool has spewed out. Glancing through these several are init time allocations that cannot be recovered from on failure, one is even a deliberate out of range bug check.

None of this has anything to do with bluetooth.

If you want this stuff to be useful then

a) check the context
b) send patches to fix stuff

we can all run scanners.