linux-kernel - Re: [PATCH V2] loop: Add sanity check for read/write

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]

Message-ID: <20250426015028.277421-1-lizhi.xu@windriver.com>
Date: Sat, 26 Apr 2025 09:50:28 +0800
From: Lizhi Xu <lizhi.xu@...driver.com>
To: <hch@...radead.org>
CC: <axboe@...nel.dk>, <linux-block@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <lizhi.xu@...driver.com>,
        <ming.lei@...hat.com>,
        <syzbot+6af973a3b8dfd2faefdc@...kaller.appspotmail.com>,
        <syzkaller-bugs@...glegroups.com>
Subject: Re: [PATCH V2] loop: Add sanity check for read/write_iter

On Fri, 25 Apr 2025 06:28:43 -0700, Christoph Hellwig wrote:
> > Some file systems do not support read_iter or write_iter, such as selinuxfs
> > in this issue.
> > So before calling them, first confirm that the interface is supported and
> > then call it.
> 
> Nit: commit messages should not have lines longer than 73 characters.
> 
> Please also add a:
> 
> Fixes: f2fed441c69b ("loop: stop using vfs_iter__{read,write} for buffered I/O")
OK, I would deal with both of the things you mentioned above.
> 
> and maybe add a blurb that vfs_iter_read/write had this check.
It makes no sence. The current issue context does not involve vfs layer
iter_read/write related routines.
> 
> Now the other interesting bit is why we did not hit this earlier with
> direct I/O?  I guess it's because we basically have no instances
> supporting direct I/O and not using the iter ops.
> 
> > @@ -603,6 +603,12 @@ static int loop_change_fd(struct loop_device *lo, struct block_device *bdev,
> >  	if (!file)
> >  		return -EBADF;
> >
> > +	if (unlikely(!file->f_op->read_iter))
> > +		return -EINVAL;
> > +
> > +	if (file->f_mode & FMODE_WRITE && unlikely(!file->f_op->write_iter))
> > +		return -EINVAL;
> 
> Can we have a common helper for change_fd and configure, please?
The common helper is not very meaningful for this case, but it may be
useful later, so it can be added.
> 
> Please also drop the unlikelys - this is not a fast path and we don't
> need to micro-optimize.
Yes, you are right, I will drop it.
> 
> A bit unrelated, but loop-configure actually checks for write_iter
> and forces read-only for that.  Do we need the same kind of check in
> change_fd?
In the context of this case, it is necessary to judge the write mode of
the new file.