Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp71669pxk; Wed, 16 Sep 2020 19:16:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyf3P636BD0Ho7+r8PW1k2b/QzJDzeCBiwYjiybn5aukVvrvKlHdjh8j8mNEwL2yCVlk3S8 X-Received: by 2002:aa7:ca4f:: with SMTP id j15mr27033401edt.233.1600308989156; Wed, 16 Sep 2020 19:16:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600308989; cv=none; d=google.com; s=arc-20160816; b=EHE7kol/orRNreo6UwEeTSSn9zzKTI0YaA+2gGcu4h5A8SbLw4vNIRrzi/34AqoIQE +Agdd6z0TLCNroTvX7gxNN9JuTMcLKeUoRRw+Ep7yZJDVXaU/Nbf72WUfq+nc5r0PG3o rA6FbI6fiFb2WRzIJ/uEJCNMqOjK+Zoi7rKV2jEk2HfmrxQM+it5i9eW50EPanD8Ri9i bCGYpVyG44Q67c7QCW1DLKO0A/n1a+JrOJiaJd8E6/Xh40HeCaU8SREk94fNmBgyVpis +kzYaQkX3Ve0kNU1p3CRKhNyfMupKcGfFYhVuPwnhiZNsQzBxzFwch/NF94Z1i4ypZME N+1g== 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=vzuy7Mz1HN5TGwOLQW39cVW5eDAEscUI2s0C9MXAhGo=; b=yJ8d1yS2ddIiEvIa82oxfhdlFWA53wpLrkjHvjDFQjvuqRPiEl0p1oQNZsYYnx0tpf jEc+8G6mDMHB6P5WDbr13Wv6xGI4n7olp4b/Y+4dza13wM6ApXBoc/vxLk+kzPrFMDDx Sk9OL9gwaa/KUi7fcQmPm9XAbQT04fq2gHYn5HOuESuU2Qw8+wdHfFL03jNAjT8g4R/9 Lg+KpyeUN1D8tij8eeG35wjd8qb3Nph9PsskGbtAi3AqVqmOat+WnZ8SK1hlC3rHF8rl zc1yhK+rrpxbrZOrl74ff3jOU12asi/v1rLJPrly99/Ym9f6hgrB2CJucPc2NhdPbERG NAhw== 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 bt10si13157649edb.554.2020.09.16.19.16.06; Wed, 16 Sep 2020 19:16:29 -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 S1726260AbgIQCOo (ORCPT + 99 others); Wed, 16 Sep 2020 22:14:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726047AbgIQCOn (ORCPT ); Wed, 16 Sep 2020 22:14:43 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F29BEC06174A; Wed, 16 Sep 2020 19:14:42 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIjRX-00088p-UJ; Thu, 17 Sep 2020 02:14:40 +0000 Date: Thu, 17 Sep 2020 03:14:39 +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: <20200917021439.GA31009@ZenIV.linux.org.uk> References: <20200911215903.GA16973@lca.pw> <20200911235511.GB3421308@ZenIV.linux.org.uk> <87ded87d232d9cf87c9c64495bf9190be0e0b6e8.camel@redhat.com> <20200917020440.GQ3421308@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200917020440.GQ3421308@ZenIV.linux.org.uk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 17, 2020 at 03:04:40AM +0100, Al Viro wrote: > 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? Gyah... Sorry, that should be Signed-off-by: Al Viro --- diff --git a/fs/fuse/file.c b/fs/fuse/file.c index 6611ef3269a8..92de6b9b06b0 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,7 @@ fuse_direct_IO(struct kiocb *iocb, struct iov_iter *iter) else if (ret < 0 && offset + count > i_size) fuse_do_truncate(file); } + iov_iter_reexpand(iter, iov_iter_count(iter) + shortened); return ret; }