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);
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.