Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp67875pxk; Wed, 16 Sep 2020 19:08:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymo43ojkMkf9pSGkUDsBwsqGr19NHDlWYxr7ysrdYe7toPcaaN6x8wdJ/mWh3q25hAMzsl X-Received: by 2002:a17:906:30c5:: with SMTP id b5mr28991806ejb.98.1600308491403; Wed, 16 Sep 2020 19:08:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600308491; cv=none; d=google.com; s=arc-20160816; b=v/v1tSjWLeMWlCIob7db2mnYwcMDesb+e0wcvyts9QtdQRJiPbDbR5a5MDWTn7vV77 F0p+9mRE6JTxydNPDfO6yp2V5MCgHWx3xwwJzTDyIEO7gIjJIQQwFVxKb71LiIg8+uDb +w9ROG1mKwJHfz/ZtR9ahuPbiN7GmDvklfpAe7JdMTKmQ4tcIngK8ciOHDzzlAXalBW2 IPlXvEkEquBpmoA3kRYZc5URI3HdFtbxvDjIeMB+nncWiRCI7xz7jDg/f/QZl1PTwiRd kosRSQ2Qg7mtIkuGmXf/E0IiSNDH+i1OEAH6UsWAwplpXbIFYn/ZeNms+Cr3qM25sKyc 2pRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=lx1n4aE80XXgZffczWlY92h0Qe0as2aqFn+vkxR+6C4=; b=xrr7V5KqvMfa/fRqpiIhnBhTXJDf3Pfj+NBcvjfBKgXVK1dB8xXt4enzF3gBMgAN61 Nc19+jMGPRjbTneJnTcGLTy52JXYGdimyitUULBOVwkn4IPzjZ9bMUXqVuEW16RBIMlc RZx5Rsp5hjyB8Ul3QRAbzmMq5fC2H0iH0QZG/J8jpXZ8OJWrguwJk5JDiWO2r2hAtgWI oRF7t2TgUUHgb2Gj8SiNI8I2ug8iZqltm4fiaKxE7VkCmCgaTR/w97/sUUCBP4cAolEp slq6oE9kiTzo/afSuC3KTWACPDbErjQWPDcTRANInxYejNv6ZqyEpW5/0gnjGgip2Pfm ubJw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v5si13958382edx.502.2020.09.16.19.07.48; Wed, 16 Sep 2020 19:08:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726149AbgIQCEs (ORCPT + 99 others); Wed, 16 Sep 2020 22:04:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56326 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725886AbgIQCEr (ORCPT ); Wed, 16 Sep 2020 22:04:47 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21D03C06174A; Wed, 16 Sep 2020 19:04:47 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIjHs-0007uR-MF; Thu, 17 Sep 2020 02:04:40 +0000 Date: Thu, 17 Sep 2020 03:04:40 +0100 From: Al Viro To: Qian Cai Cc: torvalds@linux-foundation.org, vgoyal@redhat.com, miklos@szeredi.hu, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: slab-out-of-bounds in iov_iter_revert() Message-ID: <20200917020440.GQ3421308@ZenIV.linux.org.uk> References: <20200911215903.GA16973@lca.pw> <20200911235511.GB3421308@ZenIV.linux.org.uk> <87ded87d232d9cf87c9c64495bf9190be0e0b6e8.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ded87d232d9cf87c9c64495bf9190be0e0b6e8.camel@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 16, 2020 at 05:09:49PM -0400, Qian Cai wrote: > On Sat, 2020-09-12 at 00:55 +0100, Al Viro wrote: > > On Fri, Sep 11, 2020 at 05:59:04PM -0400, Qian Cai wrote: > > > Super easy to reproduce on today's mainline by just fuzzing for a few > > > minutes > > > on virtiofs (if it ever matters). Any thoughts? > > > > Usually happens when ->direct_IO() fucks up and reports the wrong amount > > of data written/read. We had several bugs like that in the past - see > > e.g. 85128b2be673 (fix nfs O_DIRECT advancing iov_iter too much). > > > > Had there been any recent O_DIRECT-related patches on the filesystems > > involved? > > This is only reproducible using FUSE/virtiofs so far, so I will stare at > fuse_direct_IO() until someone can beat me to it. What happens there is that it tries to play with iov_iter_truncate() in ->direct_IO() without a corresponding iov_iter_reexpand(). Could you check if the following helps? Signed-off-by: Al Viro --- diff --git a/fs/fuse/file.c b/fs/fuse/file.c index 6611ef3269a8..d3eec2e11975 100644 --- a/fs/fuse/file.c +++ b/fs/fuse/file.c @@ -3095,7 +3095,7 @@ fuse_direct_IO(struct kiocb *iocb, struct iov_iter *iter) loff_t pos = 0; struct inode *inode; loff_t i_size; - size_t count = iov_iter_count(iter); + size_t count = iov_iter_count(iter), shortened; loff_t offset = iocb->ki_pos; struct fuse_io_priv *io; @@ -3111,7 +3111,8 @@ fuse_direct_IO(struct kiocb *iocb, struct iov_iter *iter) if (offset >= i_size) return 0; iov_iter_truncate(iter, fuse_round_up(ff->fc, i_size - offset)); - count = iov_iter_count(iter); + shortened = count - iov_iter_count(iter); + count -= shortened; } io = kmalloc(sizeof(struct fuse_io_priv), GFP_KERNEL); @@ -3177,6 +3178,8 @@ fuse_direct_IO(struct kiocb *iocb, struct iov_iter *iter) else if (ret < 0 && offset + count > i_size) fuse_do_truncate(file); } + if (shortened) + iov_iter_reexpand(iter, shortened); return ret; }