linux-ext4 - Re: [PATCH 10/11] fscrypt: pass a byte length to fscrypt_zeroout

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: <20251122182926.GC1626@quark>
Date: Sat, 22 Nov 2025 10:29:26 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: Christoph Hellwig <hch@....de>
Cc: "Theodore Y. Ts'o" <tytso@....edu>, Jaegeuk Kim <jaegeuk@...nel.org>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	Chao Yu <chao@...nel.org>, Christian Brauner <brauner@...nel.org>,
	"Darrick J. Wong" <djwong@...nel.org>,
	linux-fscrypt@...r.kernel.org, linux-ext4@...r.kernel.org,
	linux-f2fs-devel@...ts.sourceforge.net,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 10/11] fscrypt: pass a byte length to
 fscrypt_zeroout_range

On Tue, Nov 18, 2025 at 07:21:53AM +0100, Christoph Hellwig wrote:
> Range lengths are usually expressed as bytes in the VFS, switch
> fscrypt_zeroout_range to this convention.
> 
> Signed-off-by: Christoph Hellwig <hch@....de>
> ---
>  fs/crypto/bio.c | 6 +++---
>  fs/ext4/inode.c | 3 ++-
>  fs/f2fs/file.c  | 2 +-
>  3 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/crypto/bio.c b/fs/crypto/bio.c
> index 235dd1c3d443..4e9893664c0f 100644
> --- a/fs/crypto/bio.c
> +++ b/fs/crypto/bio.c
> @@ -115,7 +115,7 @@ static int fscrypt_zeroout_range_inline_crypt(const struct inode *inode,
>   * @inode: the file's inode
>   * @pos: the first file logical offset (in bytes) to zero out
>   * @pblk: the first filesystem physical block to zero out
> - * @len: number of blocks to zero out
> + * @len: bytes to zero out
[...]
> int fscrypt_zeroout_range(const struct inode *inode, loff_t pos,                 
>                           sector_t sector, unsigned int len)

The type of 'len' is still unsigned int, so this reduces the maximum
length accepted by fscrypt_zeroout_range() from UINT32_MAX blocks to
UINT32_MAX bytes.  Is that really okay?

Both ext4 and f2fs call this from functions where they have the length
as a u32 number of logical blocks.  And of course both filesystems
support files longer than UINT32_MAX bytes.  So it's not clear to me.
ext4 extents have a smaller size limit, so maybe at least ext4 is okay.
But different extents can be contiguous and operated on together.  So
we'd have to check the callers of the callers, etc.

It would be safer to change the type to u64 and have the callers do
(u64)len_in_blocks << blockbits.

- Eric