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

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.

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