linux-ext4 - Re: e2fsck max blocks for huge non-extent file

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: <20250113192603.GA1950906@mit.edu>
Date: Mon, 13 Jan 2025 14:26:03 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Catalin Patulea <cronos586@...il.com>, linux-ext4@...r.kernel.org,
        Kazuya Mio <k-mio@...jp.nec.com>
Subject: Re: e2fsck max blocks for huge non-extent file

On Mon, Jan 13, 2025 at 10:35:17AM -0800, Darrick J. Wong wrote:
> 
> Hmm -- num_blocks is ... the number of "extent records", right?  And on
> a !extents file, each block mapped by an {in,}direct block counts as a
> separate "extent record", right?
> 
> In that case, I think (1U<<31) isn't quite right, because the very large
> file could have an ACL block, or (shudder) a "hurd translator block".
> So that's (1U<<31) + 2 for !extents files.
> 
> For extents files, shouldn't this be (1U<<48) + 2?  Since you /could/
> create a horrifingly large extent tree with a hojillion little
> fragments, right?  Even if it took a million years to create such a
> monster? :)

The code paths in question are only used for indirect mapped files.
The logic for handling extent-mapped files is check_blocks_extents()
in modern versions of e2fsprogs, which is why Catalin was only seeing
this for an ext3 file systems that had huge_file enabled.

You're right though that we shouldn't be using num_blocks at all for
testing for regular files or directory files that are too big, since
num_blocks include blocks for extended attribute blocks, the
ind/dind/tind blocks, etc.  We do care about num_blocks being too big
for the !huge_file case since for !huge_file file systems i_blocks is
denominated in 512 byte units, and is only 32-bits wide.  So in that
case, we *do* care about the size of the file including metadata
blocks being no more than 2TiB.

						- Ted