| 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
| ||
|
Message-ID: <20230827214518.GU3390869@ZenIV>
Date: Sun, 27 Aug 2023 22:45:18 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Christoph Hellwig <hch@....de>
Cc: Matthew Wilcox <willy@...radead.org>, Jens Axboe <axboe@...nel.dk>,
Xiubo Li <xiubli@...hat.com>,
Ilya Dryomov <idryomov@...il.com>,
Christian Brauner <brauner@...nel.org>,
Theodore Ts'o <tytso@....edu>,
Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>,
Miklos Szeredi <miklos@...redi.hu>,
Andreas Gruenbacher <agruenba@...hat.com>,
"Darrick J. Wong" <djwong@...nel.org>,
Trond Myklebust <trond.myklebust@...merspace.com>,
Anna Schumaker <anna@...nel.org>,
Damien Le Moal <dlemoal@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-block@...r.kernel.org, ceph-devel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net, cluster-devel@...hat.com,
linux-xfs@...r.kernel.org, linux-nfs@...r.kernel.org,
linux-mm@...ck.org, Hannes Reinecke <hare@...e.de>
Subject: Re: [PATCH 03/12] filemap: update ki_pos in generic_perform_write
On Sun, Aug 27, 2023 at 08:41:22PM +0100, Al Viro wrote:
> On Thu, Jun 01, 2023 at 04:58:55PM +0200, Christoph Hellwig wrote:
> > All callers of generic_perform_write need to updated ki_pos, move it into
> > common code.
>
> > @@ -4034,7 +4037,6 @@ ssize_t __generic_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
> > endbyte = pos + status - 1;
> > err = filemap_write_and_wait_range(mapping, pos, endbyte);
> > if (err == 0) {
> > - iocb->ki_pos = endbyte + 1;
> > written += status;
> > invalidate_mapping_pages(mapping,
> > pos >> PAGE_SHIFT,
> > @@ -4047,8 +4049,6 @@ ssize_t __generic_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
> > }
> > } else {
> > written = generic_perform_write(iocb, from);
> > - if (likely(written > 0))
> > - iocb->ki_pos += written;
> > }
> > out:
> > return written ? written : err;
>
> [another late reply, sorry]
>
> That part is somewhat fishy - there's a case where you return a positive value
> and advance ->ki_pos by more than that amount. I really wonder if all callers
> of ->write_iter() are OK with that. Consider e.g. this:
>
> ssize_t ksys_write(unsigned int fd, const char __user *buf, size_t count)
> {
> struct fd f = fdget_pos(fd);
> ssize_t ret = -EBADF;
>
> if (f.file) {
> loff_t pos, *ppos = file_ppos(f.file);
> if (ppos) {
> pos = *ppos;
> ppos = &pos;
> }
> ret = vfs_write(f.file, buf, count, ppos);
> if (ret >= 0 && ppos)
> f.file->f_pos = pos;
> fdput_pos(f);
> }
>
> return ret;
> }
>
> ssize_t vfs_write(struct file *file, const char __user *buf, size_t count, loff_t *pos)
> {
> ssize_t ret;
>
> if (!(file->f_mode & FMODE_WRITE))
> return -EBADF;
> if (!(file->f_mode & FMODE_CAN_WRITE))
> return -EINVAL;
> if (unlikely(!access_ok(buf, count)))
> return -EFAULT;
>
> ret = rw_verify_area(WRITE, file, pos, count);
> if (ret)
> return ret;
> if (count > MAX_RW_COUNT)
> count = MAX_RW_COUNT;
> file_start_write(file);
> if (file->f_op->write)
> ret = file->f_op->write(file, buf, count, pos);
> else if (file->f_op->write_iter)
> ret = new_sync_write(file, buf, count, pos);
> else
> ret = -EINVAL;
> if (ret > 0) {
> fsnotify_modify(file);
> add_wchar(current, ret);
> }
> inc_syscw(current);
> file_end_write(file);
> return ret;
> }
>
> static ssize_t new_sync_write(struct file *filp, const char __user *buf, size_t len, loff_t *ppos)
> {
> struct kiocb kiocb;
> struct iov_iter iter;
> ssize_t ret;
>
> init_sync_kiocb(&kiocb, filp);
> kiocb.ki_pos = (ppos ? *ppos : 0);
> iov_iter_ubuf(&iter, ITER_SOURCE, (void __user *)buf, len);
>
> ret = call_write_iter(filp, &kiocb, &iter);
> BUG_ON(ret == -EIOCBQUEUED);
> if (ret > 0 && ppos)
> *ppos = kiocb.ki_pos;
> return ret;
> }
>
> Suppose ->write_iter() ends up doing returning a positive value smaller than
> the increment of kiocb.ki_pos. What do we get? ret is positive, so
> kiocb.ki_pos gets copied into *ppos, which is ksys_write's pos and there
> we copy it into file->f_pos.
>
> Is it really OK to have write() return 4096 and advance the file position
> by 16K? AFAICS, userland wouldn't get any indication of something
> odd going on - just a short write to a regular file, with followup write
> of remaining 12K getting quietly written in the range 16K..28K.
>
> I don't remember what POSIX says about that, but it would qualify as
> nasty surprise for any userland program - sure, one can check fsync()
> results before closing the sucker and see if everything looks fine,
> but the way it's usually discussed could easily lead to assumption that
> (synchronous) O_DIRECT writes would not be affected by anything of that
> sort.
IOW, I suspect that the right thing to do would be something along the lines
of
direct_write_fallback(): on error revert the ->ki_pos update from buffered write
If we fail filemap_write_and_wait_range() on the range the buffered write went
into, we only report the "number of bytes which we direct-written", to quote
the comment in there. Which is fine, but buffered write has already advanced
iocb->ki_pos, so we need to roll that back. Otherwise we end up with e.g.
write(2) advancing position by more than the amount it reports having written.
Fixes: 182c25e9c157 "filemap: update ki_pos in generic_perform_write"
Signed-off-by: Al Viro <viro@...iv.linux.org.uk>
---
diff --git a/fs/libfs.c b/fs/libfs.c
index 5b851315eeed..712c57828c0e 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -1646,6 +1646,7 @@ ssize_t direct_write_fallback(struct kiocb *iocb, struct iov_iter *iter,
* We don't know how much we wrote, so just return the number of
* bytes which were direct-written
*/
+ iocb->ki_pos -= buffered_written;
if (direct_written)
return direct_written;
return err;
Powered by blists - more mailing lists