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

[Andrew Morton <akpm@linux-foundation.org>]

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.