• Qian Cai's avatar
    mm/slub: fix stack overruns with SLUB_STATS · a68ee057
    Qian Cai authored
    There is no need to copy SLUB_STATS items from root memcg cache to new
    memcg cache copies.  Doing so could result in stack overruns because the
    store function only accepts 0 to clear the stat and returns an error for
    everything else while the show method would print out the whole stat.
    
    Then, the mismatch of the lengths returns from show and store methods
    happens in memcg_propagate_slab_attrs():
    
    	else if (root_cache->max_attr_size < ARRAY_SIZE(mbuf))
    		buf = mbuf;
    
    max_attr_size is only 2 from slab_attr_store(), then, it uses mbuf[64]
    in show_stat() later where a bounch of sprintf() would overrun the stack
    variable.  Fix it by always allocating a page of buffer to be used in
    show_stat() if SLUB_STATS=y which should only be used for debug purpose.
    
      # echo 1 > /sys/kernel/slab/fs_cache/shrink
      BUG: KASAN: stack-out-of-bounds in number+0x421/0x6e0
      Write of size 1 at addr ffffc900256cfde0 by task kworker/76:0/53251
    
      Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
      Workqueue: memcg_kmem_cache memcg_kmem_cache_create_func
      Call Trace:
        number+0x421/0x6e0
        vsnprintf+0x451/0x8e0
        sprintf+0x9e/0xd0
        show_stat+0x124/0x1d0
        alloc_slowpath_show+0x13/0x20
        __kmem_cache_create+0x47a/0x6b0
    
      addr ffffc900256cfde0 is located in stack of task kworker/76:0/53251 at offset 0 in frame:
       process_one_work+0x0/0xb90
    
      this frame has 1 object:
       [32, 72) 'lockdep_map'
    
      Memory state around the buggy address:
       ffffc900256cfc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffffc900256cfd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      >ffffc900256cfd80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
                                                             ^
       ffffc900256cfe00: 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 00
       ffffc900256cfe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ==================================================================
      Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: __kmem_cache_create+0x6ac/0x6b0
      Workqueue: memcg_kmem_cache memcg_kmem_cache_create_func
      Call Trace:
        __kmem_cache_create+0x6ac/0x6b0
    
    Fixes: 107dab5c ("slub: slub-specific propagation changes")
    Signed-off-by: default avatarQian Cai <cai@lca.pw>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Cc: Glauber Costa <glauber@scylladb.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Link: http://lkml.kernel.org/r/20200429222356.4322-1-cai@lca.pwSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    a68ee057
slub.c 146 KB