linux-kernel - Re: [PATCH] mm, mempool: kasan: poison mempool elements

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] [day] [month] [year] [list]

Message-id: <55226FA7.30505@samsung.com>
Date:	Mon, 06 Apr 2015 14:36:07 +0300
From:	Andrey Ryabinin <a.ryabinin@...sung.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	David Rientjes <rientjes@...gle.com>,
	Dave Kleikamp <shaggy@...nel.org>,
	Christoph Hellwig <hch@....de>,
	Sebastian Ott <sebott@...ux.vnet.ibm.com>,
	Mikulas Patocka <mpatocka@...hat.com>,
	Catalin Marinas <catalin.marinas@....com>,
	LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
	jfs-discussion@...ts.sourceforge.net,
	Dmitry Chernenkov <drcheren@...il.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Alexander Potapenko <glider@...gle.com>
Subject: Re: [PATCH] mm, mempool: kasan: poison mempool elements

On 04/04/2015 01:07 AM, Andrew Morton wrote:
> On Fri, 03 Apr 2015 17:47:47 +0300 Andrey Ryabinin <a.ryabinin@...sung.com> wrote:
> 
>> Mempools keep allocated objects in reserved for situations
>> when ordinary allocation may not be possible to satisfy.
>> These objects shouldn't be accessed before they leave
>> the pool.
>> This patch poison elements when get into the pool
>> and unpoison when they leave it. This will let KASan
>> to detect use-after-free of mempool's elements.
>>
>> ...
>>
>> +static void kasan_poison_element(mempool_t *pool, void *element)
>> +{
>> +	if (pool->alloc == mempool_alloc_slab)
>> +		kasan_slab_free(pool->pool_data, element);
>> +	if (pool->alloc == mempool_kmalloc)
>> +		kasan_kfree(element);
>> +	if (pool->alloc == mempool_alloc_pages)
>> +		kasan_free_pages(element, (unsigned long)pool->pool_data);
>> +}
> 
> We recently discovered that mempool pages (from alloc_pages, not slab)
> can be in highmem.  But kasan apepars to handle highmem pages (by
> baling out) so we should be OK with that.
> 
> Can kasan be taught to use kmap_atomic() or is it more complicated than
> that?  It probably isn't worthwhile - highmem pages don'[t get used by the
> kernel much and most bugs will be found using 64-bit testing anyway.
> 

kasan could only tell whether it's ok to use some virtual address or not.
So it can't be used for catching use after free of highmem page.
If highmem page was kmapped at some address than it's ok to dereference that address.
However, kasan can be used to unpoison/poison kmapped/kunmapped addresses to find use-after-kunmap bugs.
AFAIK kunmap has some sort of lazy unmap logic and kunmaped page might be still accessible for some time.

Another idea - poison lowmem pages if they were allocated with __GFP_HIGHMEM, unpoison them only on kmap, and poison back on kunmap.
Generally such pages shouldn't be accessed without mapping them first.
However it might be some false-positives. User could check if page is in lowmem and don't use kmap in that case.
It probably isn't worthwhile as well - 32bit testing will find these bugs without kasan.
--
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/