Re: [syzbot] INFO: task hung in ext4_fallocate

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux