Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Mon, 14 Aug 2023 18:05:36 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Muhammad Usama Anjum <usama.anjum@collabora.com>
Cc:     syzbot <syzbot+a8068dd81edde0186829@syzkaller.appspotmail.com>,
        syzkaller-lts-bugs@googlegroups.com, linux-ext4@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        linux-stable <stable@vger.kernel.org>,
        regressions@lists.linux.dev, Baokun Li <libaokun1@huawei.com>,
        Andreas Dilger <adilger.kernel@dilger.ca>,
        Jan Kara <jack@suse.cz>
Subject: Re: [v6.1] kernel BUG in ext4_writepages
Message-ID: <20230814220536.GE2247938@mit.edu>
References: <00000000000081f8c905f6c24e0d@google.com>
 <87dcdf62-8a74-1fbf-5f10-f4f3231f774f@collabora.com>
 <4637f58c-1cf3-0691-4fc1-6fbc38ec47ce@collabora.com>
 <0fc2546b-da7c-aac4-b402-3ef4970a1789@collabora.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0fc2546b-da7c-aac4-b402-3ef4970a1789@collabora.com>
Precedence: bulk

On Mon, Aug 14, 2023 at 10:35:57AM +0500, Muhammad Usama Anjum wrote:
> > The last refactoring was done by 4e7ea81db53465 on this code in 2013. The
> > code segment in question is present from even before that. It means that
> > this bug is present for several years. 4.14 is the most old kernel being
> > maintained today. So it affects all current LTS and mainline kernels. I'll
> > report 4e7ea81db53465 with regzbot for proper tracking. Thus probably the
> > bug report will get associated with all LTS kernels as well.
> > 
> > #regzbot title: Race condition between buffer write and page_mkwrite
> 
> #regzbot title: ext4: Race condition between buffer write and page_mkwrite

If it's a long-standing bug, then it's really not something I consider
a regression.  That being said, you're assuming that the refactoring
is what has introduced the bug; that's not necessarily case.

*Especially* if it requires a maliciously fuzzed file system, since
you have to be root to mount a file system.  That's the other thing;
the different reports at the console have different reproducers, and
at least one of them has a very badly corrupted file system --- and
since you need to have root to mount the a maliciously fuzzed file
system, these are treated with a much lower priority as far as I'm
concerned.

(If you think it should be higher priority, and your company is
willing to fund such work, patches are greatfully appreciated.  :-)

I tried to reproduce this using one of the reproducers on a modern
kernel, and it doesn't reproduce there.  That being said, it's not
entirely what the reproducer is doing, since (a) passing -1 to the
in_fd and out_fd to sendfile *should* just cause sendfile to to return
an EBADF error, and (b) when I ran it, it just segfaulted on an mmap()
before it executed anything interesting.

Please let me know (a) if you can replicate this on the latest
upstream kernel, and (b) if the reproducer doesn't require a
maliciously fuzzed kernel, or where the reproducer is scribbling on
the file system image while it is mounted.

Cheers,

						- Ted