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@xxxxxxxxx> > Reported-by: syzbot+d2125fcb6aa8c4276fd2@xxxxxxxxxxxxxxxxxxxxxxxxx > 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.
