[PATCH 0/2] fs: fix readdir position truncation on 32-bit kernels

[PATCH 0/2] fs: fix readdir position truncation on 32-bit kernels

[Zhan Xusheng]

Both ext4 and ocfs2 rebuild the directory cookie in ->iterate with

	ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;

ctx->pos is loff_t (64-bit) but sb->s_blocksize is unsigned long. On
32-bit kernels unsigned long is 32-bit, so ~(sb->s_blocksize - 1) is a
32-bit value (e.g. 0xfffff000 for 4 KiB) and, under the usual arithmetic
conversions, is zero-extended to 0x00000000fffff000 in the AND with the
64-bit ctx->pos. The high 32 bits of ctx->pos are silently cleared even
though a directory may exceed 4 GiB.

When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position
is reset back into the first 4 GiB, and the re-validation path then
re-enumerates already-returned dirents indefinitely.

These are the block-offset (non-hashed) readdir paths: ocfs2's
extent-list path (ocfs2_dir_foreach_blk_el(), used for all non-inline
directories) and ext4's linear path (non-indexed directories, or the
ext4_dx_readdir() ERR_BAD_DX_DIR fallback).

This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix
bitwise operation having different size") fixed in exfat. Cast the mask
operand to loff_t so the AND is performed in 64-bit. 64-bit kernels are
unaffected.

The two filesystems are independent; they are sent together only because
the bug and the fix are identical, so each maintainer can pick the
relevant patch. The truncation was verified with a freestanding 32-bit
test mirroring the expression; not reproduced on a live 32-bit >4 GiB
directory.

Zhan Xusheng (2):
  ext4: fix readdir position truncation on 32-bit kernels
  ocfs2: fix readdir position truncation on 32-bit kernels

 fs/ext4/dir.c  | 2 +-
 fs/ocfs2/dir.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.43.0

[PATCH 1/2] ext4: fix readdir position truncation on 32-bit kernels

[Zhan Xusheng]

In ext4_readdir(), the directory cookie position is rebuilt with

	ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;

`ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is
unsigned long.  On 32-bit kernels unsigned long is 32-bit, so the mask

	~(sb->s_blocksize - 1)

is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB
block size).  In the AND expression with the 64-bit `ctx->pos`, that
unsigned operand is zero-extended to 64 bits per the usual arithmetic
conversions, yielding 0x00000000fffff000.  The high 32 bits of
`ctx->pos` are silently cleared, even though directory size is
allowed to exceed 4 GiB on 32-bit (s_maxbytes for ext4 is many TiB).

When readdir() crosses the 4 GiB boundary on a 32-bit kernel the
position is reset back into the first 4 GiB block, making the
re-validation path re-enumerate already-returned dirents indefinitely.

ext4_readdir() reaches this linear path for non-indexed directories, and
as the fallback after ext4_dx_readdir() returns ERR_BAD_DX_DIR, so a
directory large enough to cross 4 GiB can hit it.

This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix
bitwise operation having different size") fixed in exfat.  Cast the
operand to loff_t so the mask is 64-bit before the AND:

	ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;

64-bit kernels are unaffected (unsigned long is 64-bit there, no
truncation occurs).

The truncation was confirmed with a freestanding 32-bit test program
mirroring the kernel expression: input ctx->pos = 0x100000100 produces
output 0x100 with the unfixed expression and 0x100000100 with the
cast.

Fixes: ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3")
Cc: stable@vger.kernel.org
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
---
 fs/ext4/dir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c
index 17edd678fa87..8113f43d4989 100644
--- a/fs/ext4/dir.c
+++ b/fs/ext4/dir.c
@@ -252,7 +252,7 @@ static int ext4_readdir(struct file *file, struct dir_context *ctx)
 							    sb->s_blocksize);
 			}
 			offset = i;
-			ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1))
+			ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1))
 				| offset;
 			info->cookie = inode_query_iversion(inode);
 		}
-- 
2.43.0

[PATCH 2/2] ocfs2: fix readdir position truncation on 32-bit kernels

[Zhan Xusheng]

In ocfs2_dir_foreach_blk_el(), the directory cookie position is
rebuilt with

	ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;

`ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is
unsigned long.  On 32-bit kernels unsigned long is 32-bit, so the mask

	~(sb->s_blocksize - 1)

is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB
block size).  In the AND expression with the 64-bit `ctx->pos`, that
unsigned operand is zero-extended to 64 bits per the usual arithmetic
conversions, yielding 0x00000000fffff000.  The high 32 bits of
`ctx->pos` are silently cleared, even though directory size is
allowed to exceed 4 GiB.

When readdir() crosses the 4 GiB boundary on a 32-bit kernel the
position is reset back into the first 4 GiB block, making the
re-validation path re-enumerate already-returned dirents indefinitely.

This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken
for all non-inline directories, so a directory large enough to cross
4 GiB reaches it.

This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix
bitwise operation having different size") fixed in exfat, and the
fix mirrors the equivalent ext4 fix in this series.  Cast the operand
to loff_t so the mask is 64-bit before the AND:

	ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;

64-bit kernels are unaffected.

Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem")
Cc: stable@vger.kernel.org
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
---
 fs/ocfs2/dir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index d7fc3cccf2f4..c30a86856d5b 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -1917,7 +1917,7 @@ static int ocfs2_dir_foreach_blk_el(struct inode *inode,
 				i += le16_to_cpu(de->rec_len);
 			}
 			offset = i;
-			ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1))
+			ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1))
 				| offset;
 			*f_version = inode_query_iversion(inode);
 		}
-- 
2.43.0

Re: [PATCH 0/2] fs: fix readdir position truncation on 32-bit kernels

[Andrew Morton]

On Thu,  6 Aug 2026 10:20:42 +0800 Zhan Xusheng <zhanxusheng1024@gmail.com> wrote:

> Both ext4 and ocfs2 rebuild the directory cookie in ->iterate with
> 
> 	ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;
> 
> ctx->pos is loff_t (64-bit) but sb->s_blocksize is unsigned long. On
> 32-bit kernels unsigned long is 32-bit, so ~(sb->s_blocksize - 1) is a
> 32-bit value (e.g. 0xfffff000 for 4 KiB) and, under the usual arithmetic
> conversions, is zero-extended to 0x00000000fffff000 in the AND with the
> 64-bit ctx->pos. The high 32 bits of ctx->pos are silently cleared even
> though a directory may exceed 4 GiB.
> 
> When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position
> is reset back into the first 4 GiB, and the re-validation path then
> re-enumerates already-returned dirents indefinitely.
> 
> These are the block-offset (non-hashed) readdir paths: ocfs2's
> extent-list path (ocfs2_dir_foreach_blk_el(), used for all non-inline
> directories) and ext4's linear path (non-indexed directories, or the
> ext4_dx_readdir() ERR_BAD_DX_DIR fallback).
> 
> This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix
> bitwise operation having different size") fixed in exfat. Cast the mask
> operand to loff_t so the AND is performed in 64-bit. 64-bit kernels are
> unaffected.

I'm suspecting that AI was used in this work.  If so, please see the
"Assisted-by" info in Documentation/process/submitting-patches.rst.

> The two filesystems are independent; they are sent together only because
> the bug and the fix are identical, so each maintainer can pick the
> relevant patch. The truncation was verified with a freestanding 32-bit
> test mirroring the expression; not reproduced on a live 32-bit >4 GiB
> directory.

Yeah, probably best to send these as separate standalone patches.

No matter, I'll grab the ocfs2 patch and shall await maintainer review.
 

Re: [PATCH 2/2] ocfs2: fix readdir position truncation on 32-bit kernels

[Andrew Morton]

On Thu,  6 Aug 2026 10:20:44 +0800 Zhan Xusheng <zhanxusheng1024@gmail.com> wrote:

> In ocfs2_dir_foreach_blk_el(), the directory cookie position is
> rebuilt with
> 
> 	ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;
> 
> `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is
> unsigned long.  On 32-bit kernels unsigned long is 32-bit, so the mask
> 
> 	~(sb->s_blocksize - 1)
> 
> is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB
> block size).  In the AND expression with the 64-bit `ctx->pos`, that
> unsigned operand is zero-extended to 64 bits per the usual arithmetic
> conversions, yielding 0x00000000fffff000.  The high 32 bits of
> `ctx->pos` are silently cleared, even though directory size is
> allowed to exceed 4 GiB.
> 
> When readdir() crosses the 4 GiB boundary on a 32-bit kernel the
> position is reset back into the first 4 GiB block, making the
> re-validation path re-enumerate already-returned dirents indefinitely.
> 
> This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken
> for all non-inline directories, so a directory large enough to cross
> 4 GiB reaches it.
> 
> This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix
> bitwise operation having different size") fixed in exfat, and the
> fix mirrors the equivalent ext4 fix in this series.  Cast the operand
> to loff_t so the mask is 64-bit before the AND:
> 
> 	ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;
> 
> 64-bit kernels are unaffected.

AI review had no comment on your change, but it might have found a
bunch of unrelated ocfs2 issues:

	https://sashiko.dev/#/patchset/20260806022044.167962-1-zhanxusheng@xiaomi.com

Re: [PATCH 1/2] ext4: fix readdir position truncation on 32-bit kernels

[Jan Kara]

On Thu 06-08-26 10:20:43, Zhan Xusheng wrote:
> In ext4_readdir(), the directory cookie position is rebuilt with
> 
> 	ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;
> 
> `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is
> unsigned long.  On 32-bit kernels unsigned long is 32-bit, so the mask
> 
> 	~(sb->s_blocksize - 1)
> 
> is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB
> block size).  In the AND expression with the 64-bit `ctx->pos`, that
> unsigned operand is zero-extended to 64 bits per the usual arithmetic
> conversions, yielding 0x00000000fffff000.  The high 32 bits of
> `ctx->pos` are silently cleared, even though directory size is
> allowed to exceed 4 GiB on 32-bit (s_maxbytes for ext4 is many TiB).
> 
> When readdir() crosses the 4 GiB boundary on a 32-bit kernel the
> position is reset back into the first 4 GiB block, making the
> re-validation path re-enumerate already-returned dirents indefinitely.
> 
> ext4_readdir() reaches this linear path for non-indexed directories, and
> as the fallback after ext4_dx_readdir() returns ERR_BAD_DX_DIR, so a
> directory large enough to cross 4 GiB can hit it.
> 
> This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix
> bitwise operation having different size") fixed in exfat.  Cast the
> operand to loff_t so the mask is 64-bit before the AND:
> 
> 	ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;
> 
> 64-bit kernels are unaffected (unsigned long is 64-bit there, no
> truncation occurs).
> 
> The truncation was confirmed with a freestanding 32-bit test program
> mirroring the kernel expression: input ctx->pos = 0x100000100 produces
> output 0x100 with the unfixed expression and 0x100000100 with the
> cast.
> 
> Fixes: ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>

I'll note this is a very theoretical issue. I don't think your life it long
enough to create a 4GB non-indexed directory in ext4 :) (due to quadratic
complexity of the adding of directory entry). But the fix is right so feel
free to add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  fs/ext4/dir.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c
> index 17edd678fa87..8113f43d4989 100644
> --- a/fs/ext4/dir.c
> +++ b/fs/ext4/dir.c
> @@ -252,7 +252,7 @@ static int ext4_readdir(struct file *file, struct dir_context *ctx)
>  							    sb->s_blocksize);
>  			}
>  			offset = i;
> -			ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1))
> +			ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1))
>  				| offset;
>  			info->cookie = inode_query_iversion(inode);
>  		}
> -- 
> 2.43.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH 2/2] ocfs2: fix readdir position truncation on 32-bit kernels

[Joseph Qi]

On 8/6/26 12:42 PM, Andrew Morton wrote:
> On Thu,  6 Aug 2026 10:20:44 +0800 Zhan Xusheng <zhanxusheng1024@gmail.com> wrote:
> 
>> In ocfs2_dir_foreach_blk_el(), the directory cookie position is
>> rebuilt with
>>
>> 	ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;
>>
>> `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is
>> unsigned long.  On 32-bit kernels unsigned long is 32-bit, so the mask
>>
>> 	~(sb->s_blocksize - 1)
>>
>> is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB
>> block size).  In the AND expression with the 64-bit `ctx->pos`, that
>> unsigned operand is zero-extended to 64 bits per the usual arithmetic
>> conversions, yielding 0x00000000fffff000.  The high 32 bits of
>> `ctx->pos` are silently cleared, even though directory size is
>> allowed to exceed 4 GiB.
>>
>> When readdir() crosses the 4 GiB boundary on a 32-bit kernel the
>> position is reset back into the first 4 GiB block, making the
>> re-validation path re-enumerate already-returned dirents indefinitely.
>>
>> This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken
>> for all non-inline directories, so a directory large enough to cross
>> 4 GiB reaches it.
>>
>> This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix
>> bitwise operation having different size") fixed in exfat, and the
>> fix mirrors the equivalent ext4 fix in this series.  Cast the operand
>> to loff_t so the mask is 64-bit before the AND:
>>
>> 	ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;
>>
>> 64-bit kernels are unaffected.
> 
> AI review had no comment on your change, but it might have found a
> bunch of unrelated ocfs2 issues:
> 
> 	https://sashiko.dev/#/patchset/20260806022044.167962-1-zhanxusheng@xiaomi.com

It looks fine.
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>

For the issues founded by sashiko, I'd rather track them in a separate
thread.
So Xusheng, could you please send a new fix for that? It seems enough
to do the same check like ocfs2_check_dir_entry(). e.g.

i + OCFS2_DIR_REC_LEN(1) <= sb->s_blocksize

Thanks,
Joseph

Re: [PATCH 0/2] fs: fix readdir position truncation on 32-bit kernels

[Zhan Xusheng]

From: Zhan Xusheng <zhanxusheng1024@gmail.com>

On Wed, 5 Aug 2026 21:39:46 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> I'm suspecting that AI was used in this work.  If so, please see the
> "Assisted-by" info in Documentation/process/submitting-patches.rst.

You are right, and thank you for the pointer. I used an AI coding
assistant for the analysis and drafting of this work. Per
Documentation/process/coding-assistants.rst the tag is:

	Assisted-by: Kiro:claude-opus-4.8

Could you please add that to the ocfs2 patch you picked up? I will
include it on all future submissions. Apologies for omitting it here.

> Yeah, probably best to send these as separate standalone patches.

Understood; I will send unrelated fixes as separate standalone patches
from now on.

Thanks,
Zhan Xusheng