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]
Date:	Mon, 12 Mar 2012 10:22:26 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Xiaotian Feng <xtfeng@...il.com>
Cc:	linux-kernel@...r.kernel.org, Xiaotian Feng <xtfeng@...il.com>,
	Xiaotian Feng <dannyfeng@...cent.com>,
	Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH] block: fix ioc leak in put_io_context

On Mon, Mar 12, 2012 at 10:59:18AM -0400, Xiaotian Feng wrote:
> When put_io_context is called, if ioc->icq_list is empty and refcount
> is 1, kernel will not free the ioc.
> 
> This is caught by following kmemleak:
> 
> unreferenced object 0xffff880036349fe0 (size 216):
>   comm "sh", pid 2137, jiffies 4294931140 (age 290579.412s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>     01 00 01 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
>   backtrace:
>     [<ffffffff8169f926>] kmemleak_alloc+0x26/0x50
>     [<ffffffff81195a9c>] kmem_cache_alloc_node+0x1cc/0x2a0
>     [<ffffffff81356b67>] create_io_context_slowpath+0x27/0x130
>     [<ffffffff81356d2b>] get_task_io_context+0xbb/0xf0
>     [<ffffffff81055f0e>] copy_process+0x188e/0x18b0
>     [<ffffffff8105609b>] do_fork+0x11b/0x420
>     [<ffffffff810247f8>] sys_clone+0x28/0x30
>     [<ffffffff816d3373>] stub_clone+0x13/0x20
>     [<ffffffffffffffff>] 0xffffffffffffffff
> 
> ioc->release_work() should be used even if ioc->icq_list is empty.
> 
> Signed-off-by: Xiaotian Feng <dannyfeng@...cent.com>
> Cc: Tejun Heo <tj@...nel.org>
> Cc: Jens Axboe <axboe@...nel.dk> 
> ---
>  block/blk-ioc.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/block/blk-ioc.c b/block/blk-ioc.c
> index 8b782a6..d74a8ce 100644
> --- a/block/blk-ioc.c
> +++ b/block/blk-ioc.c
> @@ -157,8 +157,7 @@ void put_io_context(struct io_context *ioc)
>  	 */
>  	if (atomic_long_dec_and_test(&ioc->refcount)) {
>  		spin_lock_irqsave(&ioc->lock, flags);
> -		if (!hlist_empty(&ioc->icq_list))
> -			schedule_work(&ioc->release_work);
> +		schedule_work(&ioc->release_work);
>  		spin_unlock_irqrestore(&ioc->lock, flags);

May be free the ioc right here instead of invoking release_work(). 

Thanks
Vivek
--
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