linux-kernel - [linux-next-20130422] Bug in SLAB?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp>
Date:	Thu, 25 Apr 2013 21:20:47 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	glommer@...allels.com, cl@...ux.com, penberg@...nel.org
Cc:	linux-kernel@...r.kernel.org
Subject: [linux-next-20130422] Bug in SLAB?

Tetsuo Handa wrote:
> Hello.
> 
> linux-next-20130422 does not boot when built with CONFIG_DEBUG_SLAB=y &&
> CONFIG_DEBUG_SPINLOCK=y && CONFIG_DEBUG_PAGEALLOC=y .
> 
> It hangs (with CPU#0 spinning) immediately after printing
> 
>   Decompressing Linux... Parsing ELF... done.
>   Booting the kernel.
> 
> lines.
> 
> Config is at http://I-love.SAKURA.ne.jp/tmp/config-3.9-rc8-next-20130422 .
> 
> Any clue before starting bisection?
> 
> Regards.
> 

Bisection (with a build fix from commit db845067 "slab: Fixup
CONFIG_PAGE_ALLOC/DEBUG_SLAB_LEAK sections") reached commit e3366016
"slab: Use common kmalloc_index/kmalloc_size functions".
Would you have a look at commit e3366016?



By the way, I have a fear regarding commit e3366016.

include/linux/slab_def.h says

  extern struct kmem_cache *kmalloc_caches[PAGE_SHIFT + MAX_ORDER];
  extern struct kmem_cache *kmalloc_dma_caches[PAGE_SHIFT + MAX_ORDER];

while mm/slab.c says

  struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1];
  struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH + 1];

and include/linux/slab.h says

  #define KMALLOC_SHIFT_HIGH      ((MAX_ORDER + PAGE_SHIFT - 1) <= 25 ? \
                                  (MAX_ORDER + PAGE_SHIFT - 1) : 25)

.

If (MAX_ORDER + PAGE_SHIFT - 1) <= 25 is true, mm/slab.c will allocate

  struct kmem_cache *kmalloc_caches[MAX_ORDER + PAGE_SHIFT - 1 + 1];
  struct kmem_cache *kmalloc_dma_caches[MAX_ORDER + PAGE_SHIFT - 1 + 1];

which matches the size declared in include/linux/slab_def.h .

If (MAX_ORDER + PAGE_SHIFT - 1) > 25 is true (I don't know whether such case
happens), mm/slab.c will allocate

  struct kmem_cache *kmalloc_caches[25 + 1];
  struct kmem_cache *kmalloc_dma_caches[25 + 1];

which is smaller than the size declared in include/linux/slab_def.h .

Well, this mismatch seems to be fixed by commit 9425c58e "slab: Common
definition for the array of kmalloc caches". But usage like

  for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) {
          struct kmem_cache_node *n;
          struct kmem_cache *cache = kmalloc_caches[i];

is remaining.

Also, kmalloc_index() in include/linux/slab.h can return 0 to 26.

If (MAX_ORDER + PAGE_SHIFT - 1) > 25 is true and
kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case
happens), kmalloc_caches[26] is beyond the array, for kmalloc_caches[26]
allows 0 to 25.

If (MAX_ORDER + PAGE_SHIFT - 1) <= 25 is true and
kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case
happens), kmalloc_caches[26] is beyond the array, for
kmalloc_caches[MAX_ORDER + PAGE_SHIFT] allows 0 to MAX_ORDER + PAGE_SHIFT - 1.

Would you recheck that the array size is correct?



Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/