From: Al Viro <viro@zeniv.linux.org.uk>
To: Daniel Yang <danielyangkang@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
"open list:FILESYSTEMS (VFS and infrastructure)"
<linux-fsdevel@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
syzbot+d2125fcb6aa8c4276fd2@syzkaller.appspotmail.com
Subject: Re: [PATCH] fix: general protection fault in iter_file_splice_write
Date: Mon, 4 Nov 2024 17:12:51 +0000 [thread overview]
Message-ID: <20241104171251.GU1350452@ZenIV> (raw)
In-Reply-To: <20241104084240.301877-1-danielyangkang@gmail.com>
On Mon, Nov 04, 2024 at 12:42:39AM -0800, Daniel Yang wrote:
> The function iter_file_splice_write() calls pipe_buf_release() which has
> a nullptr dereference in ops->release. Add check for buf->ops not null
> before calling pipe_buf_release().
>
> Signed-off-by: Daniel Yang <danielyangkang@gmail.com>
> Reported-by: syzbot+d2125fcb6aa8c4276fd2@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=d2125fcb6aa8c4276fd2
> Fixes: 2df86547b23d ("netfs: Cut over to using new writeback code")
> ---
> fs/splice.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/splice.c b/fs/splice.c
> index 06232d7e5..b8c503e47 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -756,7 +756,8 @@ iter_file_splice_write(struct pipe_inode_info *pipe, struct file *out,
> if (ret >= buf->len) {
> ret -= buf->len;
> buf->len = 0;
> - pipe_buf_release(pipe, buf);
> + if (buf->ops)
> + pipe_buf_release(pipe, buf);
> tail++;
> pipe->tail = tail;
> if (pipe->files)
Wait a minute. If nothing else, all those buffers should've passed through
pipe_buf_confirm() just prior to the call of ->write_iter(); just what had
managed to zero their ->ops and what else had that whatever it had been
done to them?
Note that pipe must've been held locked all along, so I suspect that we
ended up with ->write_iter() claiming to have consumed more than it had
been given. That could've ended up with the second loop running around
the pipe->bufs[], having already emptied each of them and trying to
find where the hell had that extra data come from.
I'd suggest checking which ->write_iter() instance had been called and
hunting for bogus return values in there. Again, ->write_iter(iocb, from)
should never return more than the value of iov_iter_count(from) prior
to the call; any instance told "write those 42 bytes" should never
reply with "here, I've written 69 of them", lest it confuses the living
fuck out of the callers.
prev parent reply other threads:[~2024-11-04 17:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-04 8:42 [PATCH] fix: general protection fault in iter_file_splice_write Daniel Yang
2024-11-04 12:06 ` Jan Kara
2024-11-04 16:54 ` Daniel Yang
2024-11-04 17:12 ` Al Viro [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241104171251.GU1350452@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=brauner@kernel.org \
--cc=danielyangkang@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+d2125fcb6aa8c4276fd2@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox