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

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251202011453.GA29113@macsyma.lan>
Date: Mon, 1 Dec 2025 20:14:53 -0500
From: "Theodore Tso" <tytso@....edu>
To: Andreas Dilger <adilger@...ger.ca>
Cc: syzbot <syzbot+bb2455d02bda0b5701e3@...kaller.appspotmail.com>,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [ext4?] possible deadlock in ext4_destroy_inline_data
 (2)

On Mon, Dec 01, 2025 at 04:17:02PM -0700, Andreas Dilger wrote:
> I think we would regret removing this if/when we *do* expand the inode
> size.  We used this functionality to upgrade filesystems online when
> i_projid was first added and users suddenly wanted to use project quotas.
> If we need some new inode field in the future it will be good to have it.

I wasn't proposing to remove the code.  I was just saying that from
the perspective of prioritization, it's not a high priority for me to
pay attention to syzbot complaints that involve this code path ---
just as it's not high priority for me to pay attentiont to syzbot
complaints that involve assuming that you should allow random
untrusted users to mount maliciously corrupted file systems --- we
should be encouraging users who want to allow people who allow their
users to pick up random USB sticks scattered in the parking lot by the
CIA or MSS and automount them as root to use fuse2fs instead.

(And by the way, it's not hard to prohibit USB sticks from being
allowed to be attached and thus making it impossible for them to be
mounted; that's how we protect things at $WORK for all desktop
systems, and ChromeOS has knobs which allow enterprise administrators
to prevent this.  It's just basically a good idea if you are a
paranoid adminstrator and are worried about nation-state attacks...
It's also makes life much easier if you are an intelligence agency and
you are worried about Snowden-style exfiltration threats; if they have
to send it out over the network, you can at least do more to detect
such activities.  :-)

In this particular syzbot complaint, it requires using a debugging
mount options that is in practice never used in the real world *and* a
malciously corrupted file system.  So it's not super high priority for
me to fix, but if we have a quick and easy fix, we should definitely
go for it, if only to shut up syzbot --- not that it will make any
difference for production use cases assuming sensible system administrators.

> This could check in ext4_orphan_cleanup()->ext4_evict_inode() path
> that this is orphan cleanup with EXT4_ORPHAN_FS and skip the expansion?
> As you write, it doesn't make sense to do that when the file is being
> deleted anyway.  Something like the following, which adds unlikely() to
> that branch since it may happen only once or never in the lifetime of
> any inode:

Something like this, but we should also skip trying to expand the
inode if i_links_count is zero.  That way, we won't try to expand an
inode if we are running rm -rf on a directory hierarchy composed of
hundreds or thousands of inodes where trying to expand the inode is a
complete waste of time.  :-)

					- Ted