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]
Date:   Fri, 13 Mar 2020 10:23:37 +1100
From:   Dave Chinner <david@...morbit.com>
To:     David Howells <dhowells@...hat.com>
Cc:     mbobrowski@...browski.org, jack@...e.cz,
        linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: Is ext4_dio_read_iter() broken?

On Thu, Mar 12, 2020 at 09:19:39AM +0000, David Howells wrote:
> Hi Matthew,
> 
> Is ext4_dio_read_iter() broken?  It calls:
> 
> 	file_accessed(iocb->ki_filp);
> 
> at the end of the function - but surely iocb should be expected to have been
> freed when iocb->ki_complete() was called?
> 
> In my cachefiles rewrite, I'm seeing the attached kasan dump.  The offending
> RIP, ext4_file_read_iter+0x12b is at the above line, where it is trying to
> read iocb->ki_filp.
> 
> Here's an excerpt of the relevant bits from my code:
> 
> 	static void cachefiles_read_complete(struct kiocb *iocb, long ret, long ret2)
> 	{
> 		struct cachefiles_kiocb *ki =
> 			container_of(iocb, struct cachefiles_kiocb, iocb);
> 		struct fscache_io_request *req = ki->req;
> 	...
> 		fput(ki->iocb.ki_filp);
> 		kfree(ki);
> 		fscache_end_io_operation(req->cookie);
> 	...
> 	}
> 
> 	int cachefiles_read(struct fscache_object *obj,
> 			    struct fscache_io_request *req,
> 			    struct iov_iter *iter)
> 	{
> 		struct cachefiles_object *object =
> 			container_of(obj, struct cachefiles_object, fscache);
> 		struct cachefiles_kiocb *ki;
> 		struct file *file = object->backing_file;
> 		ssize_t ret = -ENOBUFS;
> 	...
> 		ki = kzalloc(sizeof(struct cachefiles_kiocb), GFP_KERNEL);
> 		if (!ki)
> 			goto presubmission_error;
> 
> 		ki->iocb.ki_filp	= get_file(file);
> 		ki->iocb.ki_pos		= req->pos;
> 		ki->iocb.ki_flags	= IOCB_DIRECT;
> 		ki->iocb.ki_hint	= ki_hint_validate(file_write_hint(file));
> 		ki->iocb.ki_ioprio	= get_current_ioprio();
> 		ki->req			= req;
> 
> 		if (req->io_done)
> 			ki->iocb.ki_complete = cachefiles_read_complete;
> 
> 		ret = rw_verify_area(READ, file, &ki->iocb.ki_pos, iov_iter_count(iter));
> 		if (ret < 0)
> 			goto presubmission_error_free;
> 
> 		fscache_get_io_request(req);
> 		trace_cachefiles_read(object, file_inode(file), req);
> 		ret = call_read_iter(file, &ki->iocb, iter);
> 		...
> 	}
> 
> The allocation point, cachefiles_read+0xd0, is the kzalloc() you can see and
> the free point, cachefiles_read_complete+0x86, is the kfree() in the callback
> function.

It looks to me like you are creating your own iocb that you are
doing AIO+DIO on, and you aren't taking a reference count to the
iocb yourself to ensure that it exists for the entire submission
path. i.e. see how the AIO code uses ki_refcnt and iocb_put() to
ensure the iocb does not get destroyed by IO completion before the
submission path has completed.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ