linux-kernel - Re: Q, slab, kmemleak

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: <84144f020911220135l466247c5i9612386fcc30a28c@mail.gmail.com>
Date:	Sun, 22 Nov 2009 11:35:17 +0200
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	hooanon05@...oo.co.jp
Cc:	Catalin Marinas <catalin.marinas@....com>,
	linux-kernel@...r.kernel.org
Subject: Re: Q, slab, kmemleak_erase() and redzone?

On Fri, Nov 20, 2009 at 6:14 PM,  <hooanon05@...oo.co.jp> wrote:
> in short: Is it safe to assign NULL to the un-adjusted pointer in
>          kmemleak_erase()?
>
> in long:
> I've met a strange redzone warning at deleting a module.
>
> ----------------------------------------------------------------------
> slab error in verify_redzone_free(): cache `size-256': memory outside object was overwritten
> Pid: 5080, comm: modprobe Not tainted 2.6.32-rc7aufsD #320
> Call Trace:
>  [<ffffffff811010d1>] ? dbg_redzone2+0x31/0x70
>  [<ffffffff81101371>] __slab_error+0x21/0x30
>  [<ffffffff811022cd>] cache_free_debugcheck+0x1fd/0x300
>  [<ffffffff811041e5>] ? __kmem_cache_destroy+0x65/0x110
>  [<ffffffff81103bc0>] kfree+0x1c0/0x260
>  [<ffffffff811041e5>] __kmem_cache_destroy+0x65/0x110
>  [<ffffffff81104336>] kmem_cache_destroy+0xa6/0x100
>  [<ffffffffa03130b4>] au_cache_fin+0xb4/0xf0 [aufs]
>  [<ffffffff81458387>] ? _write_unlock+0x57/0x70
>  [<ffffffffa0348c75>] aufs_exit+0x15/0x39 [aufs]
>  [<ffffffff81095cdb>] sys_delete_module+0x19b/0x260
>  [<ffffffff81087e3d>] ? trace_hardirqs_on_caller+0x14d/0x1a0
>  [<ffffffff8145797e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
>  [<ffffffff810127c2>] system_call_fastpath+0x16/0x1b
> ffff88000e87aa40: redzone 1:0xd84156c5635688c0, redzone 2:0x0.
> ----------------------------------------------------------------------
>
> When delete_module(2) removes aufs.ko, aufs_exit() calls
> kmem_cache_destroy() (SLAB) to remove some aufs specific caches whose
> name are NOT 'size-256.' Diving into kmemcache, I found the trigger is
> in __kmem_cache_destroy(),
>        for_each_online_cpu(i)
>            kfree(cachep->array[i]);
> The 'cachep->array[i]' is in 'size-256' cache, and kfree() for it
> produced the warning.
>
> At first, I thought I made mistakes in my module and corruped
> memory. But I could not find such bug.
> Inserting some code to check the correctness of cachep->array[i] for
> size-256 everywhere led me to kmemleak_erase() in ____cache_alloc().
>
> __cache_alloc()
> {
>        objp = __do_cache_alloc(cachep, flags);
>        :::
>        objp = cache_alloc_debugcheck_after(cachep, flags, objp, caller);
>        :::
>        return objp;
> }
>
> __do_cache_alloc()
> {
>        :::
>        objp = ____cache_alloc(cache, flags);
>        :::
>        return objp;
> }
>
> ____cache_alloc()
> {
>        objp = ac->entry[--ac->avail];
>        or
>        objp = cache_alloc_refill(cachep, flags);
>        :::
>        kmemleak_erase(&ac->entry[ac->avail]);
>        return objp;
> }
>
> kmemleak_erase(void **ptr)
> {
>        *ptr = NULL;
> }
>
> cache_alloc_debugcheck_after() adjusts the passed objp by
>        objp += obj_offset(cachep);
> which is 4 or 8 bytes when CONFIG_DEBUG_SLAB is enabled (also
> cache_alloc_refill() may return NULL).
> In other words, the passed pointer to kmemleak_erase() is not adjusted
> yet.
> Is it safe to assign NULL to the un-adjusted pointer in kmemleak_erase()?

We are setting an element in the per CPU array to NULL so the the
kmemleak code in ____cache_alloc() is safe. Red-zoning is done at the
_object_ which is not touched by kmemleak. Looking at the oops, it
does seem likely that you have a bug in your module (or in some other
part of the kernel).

                        Pekka
--
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/