| 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
| ||
|
Date: Tue, 01 Dec 2009 17:56:50 +0000 From: Catalin Marinas <catalin.marinas@....com> To: Pekka Enberg <penberg@...helsinki.fi> Cc: hooanon05@...oo.co.jp, linux-kernel@...r.kernel.org Subject: Re: Q, slab, kmemleak_erase() and redzone? On Tue, 2009-12-01 at 11:49 +0000, Pekka Enberg wrote: > hooanon05@...oo.co.jp kirjoitti: > > Pekka Enberg: > >> 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). > > > > Thanks for reply. > > In ____cache_alloc(), the variable 'ac' is assigned before > > cache_alloc_refill() call, and it is used for the parameter of > > kmemleak_erase(). The value may be changed by cache_alloc_refill(), > > isn't it? > > No. The pointer returned by cpu_cache_get() is not changed by > cache_alloc_refill(). The contents of the array might change, yes. That > said, we should check if objp is NULL before calling kmemleak_erase(). Possibly but I don't understand why that's needed. The kmemleak_erase() call just sets the ac->entry[ac->avail] to NULL. If ac->avail is 0, it doesn't cause any harm. Thanks. -- Catalin -- 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/
Powered by blists - more mailing lists