linux-kernel - Re: [syzbot] [ext4?] possible deadlock in ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250825133743.GA1511874@mit.edu>
Date: Mon, 25 Aug 2025 09:37:43 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Hillf Danton <hdanton@...a.com>
Cc: syzbot <syzbot+c5c9c223a721d7353490@...kaller.appspotmail.com>,
        linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [ext4?] possible deadlock in ext4_truncate (2)

On Mon, Aug 25, 2025 at 06:41:52PM +0800, Hillf Danton wrote:
> > syzbot found the following issue on:
> > 
> > dashboard link: https://syzkaller.appspot.com/bug?extid=c5c9c223a721d7353490
> 
> --- x/fs/ext4/inode.c
> +++ y/fs/ext4/inode.c
> @@ -4573,6 +4573,7 @@ int ext4_truncate(struct inode *inode)
>  	struct ext4_inode_info *ei = EXT4_I(inode);
>  	unsigned int credits;
>  	int err = 0, err2;
> +	static int subclass = 0;
>  	handle_t *handle;
>  	struct address_space *mapping = inode->i_mapping;
>  
> @@ -4636,7 +4637,7 @@ int ext4_truncate(struct inode *inode)
>  	ext4_fc_track_inode(handle, inode);
>  	ext4_check_map_extents_env(inode);
>  
> -	down_write(&EXT4_I(inode)->i_data_sem);
> +	down_write_nested(&EXT4_I(inode)->i_data_sem, subclass++);
>  	ext4_discard_preallocations(inode);
>  
>  	if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))

This isn't the right way to fix these sorts of Syzbot failures.  First
of all, we already have subclasses defined.  Secondly, using a
continuously incrementing subclasses will chew up a huge amount of
memory until lockdep gives a warning that the kernel exceeded a fixed
limit, which (a) disables the lockdep checking, so it's counter
productive, (b) will trigger a syzbot failure, so it doesn't even shut
up the syzbot noise.

The combination of maliciously corrupted/fuzzed file systems, and a
deadlock warning, is something that I just ignore.  Your patch is an
attempt to do this programmtically, if it worked (and for better or
for worse, it doesn't).  If there was a way I could tell syzbot ---
you're just wasting everyone's time, shut up with this combination,
but there isn't.  So when I have time, I'll recategorize these reports
to priority low, which is a signal that it's been triaged, and it's
syzbot noise.

Cheers,

						- Ted