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

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