Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Date:   Mon, 18 Sep 2023 18:07:54 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Shreeya Patel <shreeya.patel@collabora.com>
Cc:     linux-ext4@vger.kernel.org,
        Ricardo =?iso-8859-1?Q?Ca=F1uelo?= 
        <ricardo.canuelo@collabora.com>,
        "gustavo.padovan@collabora.com" <gustavo.padovan@collabora.com>,
        groeck@google.com, zsm@google.com, garrick@google.com,
        Linux regressions mailing list <regressions@lists.linux.dev>
Subject: Re: [syzbot] INFO: task hung in ext4_fallocate
Message-ID: <ZQjKOjrjDYsoXBXj@mit.edu>
References: <d89989ef-e53b-050e-2916-a4f06433798b@collabora.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <d89989ef-e53b-050e-2916-a4f06433798b@collabora.com>
Precedence: bulk

On Mon, Sep 18, 2023 at 08:13:30PM +0530, Shreeya Patel wrote:
> Hi Everyone,
> 
> syzbot has reported a task hung issue in ext4_fallocate, crash report can be
> seen at the bottom of the email.

What's the link to the syzbot dashboard URL?  This is typically the
first line of the reproducer, but it's been snipped out in your
reproducer.

> 
> When I tried to reproduce this issue on mainline linux kernel using the
> reproducer provided by syzbot, I see an endless loop of following errors :-
> 
> [?? 89.689751][ T3922] loop1: detected capacity change from 0 to 512
> [?? 89.690514][ T3916] EXT4-fs error (device loop4): ext4_map_blocks:577:
> inode #3: block 9: comm poc: lblock 0 mapped to illegal pblock 9 (length 1)
> [?? 89.694709][ T3890] EXT4-fs error (device loop0): ext4_map_blocks:577:

Please note that maliciously corrupted file system is considered low
priority by ext4 developers.  If this is something which is important
to Google, then it needs to fund more headcount so that we have time
to take a look at these things.  There has been plenty of discussions
about how syzbot is effectively a denial of service attack on upstream
resources, and the only way we can respond is to down-prioritize such
bug reports.

This is *especially* true when we receive reports from private syzbot
instances where we don't have any of the features provided by syzbot
console --- including convenient access to the file system image that
was mounted as part of the test, the ability to use #syz test to try
out patches --- and more importantly, so we can introduce debugging
messages and using the syzbot testing facility to run the tests.

If you really are concerned about the threat model of users picking up
random USB thumb drives that they found in the parking lot, consider
running fsck.ext4 -f on the file system first, and if the file system
checker is not able to fix the file system, refuse to mount it.
Alternatively, consider using cros-vm, and mounting the file system in
the guest-kernel so that the VMM provides an additional sandbox layer.

Anyway, please provide a link to a public Syzkaller dashboard report,
and we'll take a look at it when we have time...

Cheers,

							- Ted