linux-ext4 - Re: Is ext4_dio_read

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: <20200312232337.GZ10737@dread.disaster.area>
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