linux-ext4 - Re: [PATCH 2/3] ext4: add support for 32-bit default reserved uid and gid values

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: <20250912025752.GC3703006@mit.edu>
Date: Thu, 11 Sep 2025 22:57:52 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: "Darrick J. Wong" <djwong@...nel.org>, G@....edu
Cc: linux-ext4@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH 2/3] ext4: add support for 32-bit default reserved uid
 and gid values

On Thu, Sep 11, 2025 at 03:31:21PM -0700, Darrick J. Wong wrote:
> 
> Is there a risk that some garbage written to s_reserved (and not caught
> by either the kernel or e2fsck) will now appear as a "legitimate" resuid
> value?

The superblock is checksumed, so the risk would be that some
impleentation modifies the superblock and updates s_reserved for some
reason.  But they could do that to any superblock field, or to the low
16 bits of s_resuid/s_resgid today, and that's something that neither
the kernel or e2fsck could check.

The mke2fs program zeroes all of the unused/reserved portions of the
superblock, so the risk is some random non-Linux implementation (e.g.,
GNU Hurd or BSD) had hijacked some reserved field without coordinating
with upstream ext4.  I thought about using some kind of compat feature
flag, but it probably wouldn't help since the other implementation
would likely not bother to use their own feature flag since that would
prevent the file system to be mounted with Linux.

Currently, someone tried to run "tune2fs -u 146878 /tmp/foo.img" we'll
silently drop the high 16 bits:

% tune2fs -u 146878 /tmp/foo.img 
tune2fs 1.47.3-rc2 (12-Jun-2025)
Setting reserved blocks uid to 146878
% dumpe2fs -h /tmp/foo.img | grep uid
dumpe2fs 1.47.3-rc2 (12-Jun-2025)
Reserved blocks uid:      15806 (user tytso)

And if we have implementations that support 32-bit reserved
uid's/gid's, and the file system is mounted on an older kernel, it
will simply use a different reserved uid (e.g., 15806 instead of
146878).  But we're kind of confused today, and in practice most of
the time people will be using low reserved uid's/gid's (e.g., 1 for
daemon, etc.).

						- Ted