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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87egpbklh3.fsf@rustcorp.com.au>
Date:	Sat, 28 Feb 2015 09:31:28 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Andrey Ryabinin <a.ryabinin@...sung.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Andrey Ryabinin <a.ryabinin@...sung.com>,
	Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [PATCH 1/2] kasan, module, vmalloc: rework shadow allocation for modules

Andrey Ryabinin <a.ryabinin@...sung.com> writes:
> Current approach in handling shadow memory for modules is broken.
>
> Shadow memory could be freed only after memory shadow corresponds
> it is no longer used.
> vfree() called from interrupt context could use memory its
> freeing to store 'struct llist_node' in it:
>
> void vfree(const void *addr)
> {
> ...
> 	if (unlikely(in_interrupt())) {
> 		struct vfree_deferred *p = this_cpu_ptr(&vfree_deferred);
> 		if (llist_add((struct llist_node *)addr, &p->list))
> 				schedule_work(&p->wq);
>
> Latter this list node used in free_work() which actually frees memory.
> Currently module_memfree() called in interrupt context will free
> shadow before freeing module's memory which could provoke kernel
> crash.
> So shadow memory should be freed after module's memory.
> However, such deallocation order could race with kasan_module_alloc()
> in module_alloc().
>
> Free shadow right before releasing vm area. At this point vfree()'d
> memory is not used anymore and yet not available for other allocations.
> New VM_KASAN flag used to indicate that vm area has dynamically allocated
> shadow memory so kasan frees shadow only if it was previously allocated.
>
> Signed-off-by: Andrey Ryabinin <a.ryabinin@...sung.com>
> Cc: Dmitry Vyukov <dvyukov@...gle.com>
> Cc: Rusty Russell <rusty@...tcorp.com.au>

Acked-by: Rusty Russell <rusty@...tcorp.com.au>

Thanks!
Rusty.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ